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ABSTRACT 


The effective use of information can enable a public agency to better serve the 
taxpayers, or provide a crucial strategic advantage for a private sector firm. Present U. 
S. Coast Guard information systems do not provide information to all potential users as 
effectively as they could. They suffer from several shortcomings: 

• Poor connectivity, resulting in an awkward, torturous information flow which 
frequently does not provide information to people who need it. 

• Significant overlap in content, resulting in increased workload and frustration for 
field personnel who enter data and data inconsistencies between applications. 

• Poor user interface designs, resulting in a situation where although information may 
be accessible to a user, it is difficult to retrieve and therefore not gotten. 

Cross-functional systems, based on a robust information architecture, offer the 
potential to dramatically improve information flow and availability within an organization. 
In the Coast Guard, the flow of operational information can be greatly improved by 
developing a cross-functional Operations Information System (OIS). Developing such 
a system is critical to continued effective service to the public, but may require changes 
in the ways in which systems are developed and funded. 
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I. INTRODUCTION 


Numerous studies have documented that the U.S. has been in the throes of an 
historic transition for the past two decades. The old industrial society that 
generated wealth in the form of capital goods and manufactured products is giving 
way to a new society valued in terms of intangible assets, such as knowledge and 
information processing. (.Business Week, June 30, 1980). 


Firms preparing to meet the challenges of the 1980's will need a capable and 
sophisticated manager of corporate information. An organization's success will be 
dependent in large part on successfully managing its information resources. (Lucas, 
1979, p. 114). 


As predicted by the first quote, and like many government agencies and businesses, 
the United States Coast Guard is increasingly discovering the strategic importance of 
information. But it is also discovering the deep implications of the second quote — 
namely, that it is not information in itself, but the effective use of that information, that 
is critically important. The effective use of information can provide private sector firms 
with significant competitive advantages. In a similar fashion, it can greatly increase the 
effectiveness of a government agency's service to the taxpayers. 

Achieving this effective information use, however, is exceedingly complex. Many 
existing information systems fall short of their potential effectiveness, for a variety of 
reasons. And almost no organization has implemented a single system that integrates all 
facets of its operations. The Coast Guard today finds itself in this situation — it has a 
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large number of information systems in use, but no single system that summarizes 
information from all functions. Today's systems are fairly successful at collecting the 
information their designers specified, which is primarily for use by headquarters staffs. 
However, few offer their information to those staffs with any flexibility in presentation, 
and few distribute any of the information to other levels in the organization for use in 
operational planning or command and control. There is a great need for information to 
flow not only up the hierarchy, but also down it, as well as across the traditional 
functional lines within the organization. 

There are two reasons for the present situation. First, most Coast Guard systems 
are typical of 1980's computing technology, in which only a few exceptional systems 
provided the complete information flow now possible. Second, information "owners" are 
sometimes reluctant to share it, since it represents organizational power. This 
"information parochialism" is present in the Coast Guard. 

A. COAST GUARD PROGRAMS AND PROGRAM MANAGERS 

The Coast Guard is responsible for four major roles: maritime law enforcement, 
national security, maritime safety, and marine environmental protection (COMDTXNST 
16000.21, 21 Sep 90). The first two each constitute operating Coast Guard "programs" 
of their own. Maritime safety includes several programs, including search and rescue, 
aids to navigation, boating safety, vessel inspection and documentation, and icebreaking. 

Each of these programs is administered by a program manager at Coast Guard 
Headquarters (CGHQ). These officers and their staffs perform planning, programming. 
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and budgeting for their respective programs, and are assisted by other "support" offices. 
The organizational structure at headquarters and in lower echelon staffs is a classic 
hierarchy, divided along functional lines. 

B. RESEARCH APPROACH 

The goal of this thesis is to make recommendations to increase the effective use of 
information by the Coast Guard, partly by a critique of existing systems. Rather than 
consider the entire suite of Coast Guard applications, the thesis examines a few 
representative systems, listed in Table 1. They were chosen for their mainstream position 
in the Coast Guard's suite of operational systems. 


TABLE 1: COAST GUARD PROGRAM MANAGERS AND INFORMATION 
SYSTEMS. 


Program: 

Program Manager: 

Information 

System: 

Search 

and 

Rescue 

G-NRS 

Office of Navigation Safety 
and Waterways Management, 
Search and Rescue Division 

SAR database 
(data input via 
SARMIS/DES, 
SARMIS/DSS) 

Law 

Enforcement 

G-OLE 

Office of Operations, 

Law Enforcement Division 

LEIS 

(data input via 
SEER, SIMS/ELT) 

Marine 

Safety 

G-M 

Office of Marine Safety, 
Security, 

and Environmental Protection 

MSIS 
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The information systems included in this study are all intended primarily for 
decision support. They include transaction processing as a necessary means of data 
capture, but the bottom-line reason for their existence is that someone needs the 
information for decision making. The decisions to be made vary in type, but can be 
broken down into two broad classes for purposes of analysis (although most systems are 
used to some extent for both decision types). 

The first category is decisions made at the operational and tactical levels. These 
are primarily command and control decisions, either in the short term or medium term. 
A typical short-term decision supported by MSIS is whether or not to perform a boarding 
on a particular vessel. The information required includes the recency of the last boarding, 
results of prior boardings, and any other information about the vessel. A typical medium 
term decision is whether to stage a boat or aircraft in a place where there normally would 
not be coverage; the information required includes the density and frequency of cases in 
that area at certain critical times of the week or year. 

The second category is decisions made at the strategic level, primarily programming 
and budgeting. 

C. FUNCTIONALITY OF OPERATIONAL SYSTEMS 

The existing operational information systems are, for the most part, fairly mature. 
Each of the systems considered in detail here has been operational since the early to mid 
1980's. They function fairly reliably, and the information they seek is collected with 
relatively low error rates, at least when compared to the manual systems they replaced. 
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(For instance, the SIMS/ELT program provides on-line validation during data entry, 
keeping error rates low. However, data entered via manually prepared SEER messages 
is frequently erroneous). 

Existing systems are still primarily aimed at collecting data for a limited range of 
uses at headquarters. Few allow any flexibility in their reports, or any interactive 
manipulation of the data to a form that would suit the user. Similarly, few provide any 
decision support to mid-level planners and operational personnel, where information 
could be extremely important to the agency's mission execution. Those that do provide 
this type of support are difficult to leam and use effectively. 

The existing generation of standalone systems could be made much more effective 
on their own merits if improvements were made in four key areas: 


• Human interface — users’ ability to learn the system quickly and use it easily once 
learned. 

• Information accessibility — systems should provide information in any form 
desired by the user, and make it easy for the user to describe what is desired. They 
should provide information to users at all organizational levels, not just the top. 

• Data communications — records should be transmitted to the central database 
before the value of the information decreases because of its age. The simple 
transmission of data should not cause users delay or frustration, but rather should 
be transparent. 

• Source-level data validation — records should be verified for accuracy at the 
source, leaving only minimal need for validity checking at the central site (i.e., to 
check for errors introduced during transmission). 


Chapter III will discuss these aspects of the Coast Guard's information systems in 


detail. 
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D. CROSS-FUNCTIONALITY OF OPERATIONAL SYSTEMS 

As a result of the individualized system development, with no coordination between 
program managers, there is little connectivity and no cross-functionality between Coast 
Guard information systems. In its 1990 report on Coast Guard Information Resources 
Management, the General Accounting Office (GAO) writes that: 

During the 1980's, the Coast Guard acquired new, expanded responsibilities - 
most notably drug enforcement and defense-related activities - in addition to its 
traditional missions of search and rescue, marine environmental protection, law 
enforcement, and defense readiness. In this multimission environment, the Coast 
Guard depends on getting large amounts of information, getting it accurately, and 
getting it on time. In many cases, however, information is not collected, readily 
available, or easily transferable among various Coast Guard units. These problems 
have affected both program operations and program management. 

The Coast Guard's law enforcement program, for example, suffers from a lack 
of readily accessible information necessary to support tactical decision-making. In 
deciding whether or not to board a vessel, timely access to information such as 
prior boardings or violations is essential to improving law enforcement. 

... Many of the Coast Guard's information systems were developed to support 
narrow program needs. Most systems are not integrated and cannot share 
information with other existing Coast Guard systems.... field offices sometimes have 
to use several different systems to obtain information on the variety of interrelated 
tasks they are performing. (GAO/IMTEC-90-32, April 1990, pp 2-4). 

This lack of cross-functionality is especially critical at field units: although one 
mission is usually primary, two or three other missions are also performed frequently. 
Consequently, information from separate systems is necessary to do a job well. 

As an example, consider the Group operations center controller who gets a report 
of an overdue vessel. These reports are received frequently by the Coast Guard, and are 
characterized by very sketchy information and high levels of concern. Rarely does the 
Coast Guard get a good description of the missing boat, its operator, or the operator's 
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habits and plans. Most of these reports are made in the evening — a typical voyage, 
especially by a recreational boat, is most likely to end in the afternoon, and the report is 
made when boat is a couple of hours late. 

In this situation, what an operations coordinator needs most of all is information. 
First, a good description is vital, because the boat must be described to all who may have 
seen it, such as marina operators, other boaters, or other agencies. Second, reporting 
sources often don't even know who owns the boat; if that information is available, a 
phone call to the owner or another related party may find that there was a change of 
plans, or that the missing party is safe in another port. Finally, LEIS contains records of 
all vessels sighted by Coast Guard units on patrol, and a check of that system may yield 
a sighting of the boat, which can narrow down the search area tremendously. 

This information is quite likely to be in one or another of the systems considered 
in this thesis. However, getting it is quite difficult. SARMIS does not allow local access 
to its data at all. SIMS/ELT does create a local database of reports by the individual unit; 
however, it doesn't contain information from the neighboring station that may help. LEIS 
contains information reported by all units in the Coast Guard, but access was recently 
provided to Group offices (it had previously been restricted to districts and above, for 
security and access reasons). Finally, MSIS contains vital ownership information on any 
commercial or documented vessel, but almost no Group offices have access to that 
system. Even if the operations center coordinator had access to these systems, getting the 
desired information is difficult because of complicated query procedures that are different 
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in each. A single, cross-functional system with a friendly user interface would surely be 
a boon. 


Chapter IV will examine current views on the tradeoffs involved in implementing 
cross-functional information systems. Chapter V will apply this material to Coast 
Guard's IRM situation. 


E. FUTURE SYSTEMS DEVELOPMENT PATH 

The Office of Command, Control and Communications (G-T) at Coast Guard 
Headquarters is committed to ensuring that the Coast Guard develops systems which are 
increasingly cross-functional, and rely on open systems technology (USCG COMDTINST 
5230.41, Aug 31 1990). Future systems development could take any of several paths, 
including the following (listed roughly in order of increasing difficulty and cost): 


• Continue routine life cycle maintenance and upgrades, but expend no effort toward 
integrating systems. Leave the data structures as they are, primarily file processing 
based. 

• Develop common user interfaces, so that each system looks and feels somewhat 
familiar to an operator who has previously used another system. However, make 
no other fundamental changes. 

• Develop a query interface that can extract data from any of the different underlying 
systems while presenting only a single interface to the user. 

• Employ database management systems, and develop similar architectures, data 
structures and data dictionaries for the various information systems to allow easier 
connectivity. 

• Develop a completely integrated information system to replace the existing ones, 
scrapping the old systems entirely. 
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The first path, the status quo, has been criticized within the Coast Guard and by »he 
GAO; it is well recognized that greater connectivity and cross-functionality are required. 
The degree to which those goals should be pursued, and the rapidity with which we 
pursue them, are the tough questions. Some work is already in progress: 


• The Corporate Database Project is a Decision Support System (DSS) whose 
database management system extracts data from several existing CG IS's, aggregates 
it, and provides a user with analytical models and a graphical user interface to allow 
sophisticated interactive manipulation of information for programming and budget 
decisions (Synetics Corp, 1990, p. 1). 

• The Office of Command, Control and Communications (G-T) has structured the 
CG Standard Workstation contract so as to encourage use of either Oracle™ or 
Progress™ as the DBMS, in order to establish a compatibility baseline. 

• Policy requires that all new systems maximize implementation of open system 
architectures, in order to allow for the most flexible possible upgrade paths and to 
enhance competition. 

• A set of Data Element Naming Conventions have been developed, for improving 
compatibility between data dictionaries. 

• Unisys Corporation, the Coast Guard Standard Workstation vendor, is implementing 
a two-pronged approach to incorporating a Graphical User Interface into BTOS 
application. First, it will support Microsoft's Presentation Manager™. Second, it 
has specified XVT™ (Extensible Virtual Terminal) as the API (Application 
Programming Interface) for BTOS applications. The resulting similarity between 
interfaces, along with increased ease of use, should make information much more 
accessible. 


F. RESEARCH FOCUS 

The primary’ purpose of this thesis is to suggest three ways in which the Coast 
Guard can improve its collection and use of information. First, where possible, it should 
improve the existing independent, functionally oriented (stovepipe) systems. Second, it 
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should aggressively develop cross-functional (or integrated) information systems. Third, 
and in close coordination with the second, it should develop a robust information 
architecture. This will be vitally important to all future systems development, whether 
the systems support a single function or are cross- functional. 

The thesis begins with an overview of existing Coast Guard information systems, 
and recommendation for improving their standalone functionality. 

The research then turns to the subject of cross-functionality. A theoretical 
foundation for the concept of cross-functionality is laid, founded in organizational 
structure, and the capability of information systems to support existing and new structures. 
These principles are then applied to the Coast Guard’s missions, organization, and 
information systems. A proposal for a cross-functional Operations Information System 
(OIS) is made, and some thought is devoted to means of motivating such a system in a 
competitive budget climate such as the one in which Coast Guard program managers find 
themselves. 
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n. OVERVIEW OF COAST GUARD INFORMATION MANAGEMENT 


This chapter presents a summary of present Coast Guard Information Resource 
Management (IRM) policy; a brief analysis of the recent past IRM policy atmosphere; an 
overview of the data communications schemes which support Coast Guard IRM; and a 
description of the Coast Guard Standard Workstation, which serves as the data entry 
terminal for nearly all of the Coast Guard's information systems. 

A. TOP-LEVEL GOALS, POLICIES, AND OBJECTIVES 

The highest level policy statement on IRM is found in Commandant Instruction 
16000.21, the Strategic Agenda of Coast Guard Commandant Admiral J.W. Kime. In this 
document, he states his desired emphasis for the Coast Guard's four primary operational 
roles (see section I.A.), as well as for two important support areas, (1) personnel support, 
and (2) information, facility, and hardware management. His IRM-related goals are: 

• Project future needs for equipment, capital and real property, and assess the 
condition, life expectancy and utility of inventory to meet current and future 
requirements, 

• Maintain a capital asset projection plan to meet current and projected needs, and 

• Increase efficiency and enhance capability through Information Resource 
Management. 
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The IRM-related policies in support of these goals are: 

• Continually survey new technologies and applications of technology which would 
improve the Coast Guard's efficiency or effectiveness, 

• Upgrade facilities and equipment as roles change, new technologies are employed, 
or obsolescence is identified, and 

• Acquire standardized equipment which improves interoperability with other agencies 
and is fully supportable within Coast Guard or other federal government resources 
(COMDTINST 16000.21, 21 Sep 90). 

Primary Coast Guard IRM policy in support of the Commandant's Strategic Agenda 
is contained in two documents: Commandant Instruction (COMDTINST) 5230.41, and 
COMDTINST 5230.38. 

COMDTINST 5230.38, Designated Senior Official (DSO) for Information Resource 

Management (IRM), begins by defining IRM: 

IRM was officially introduced into the Federal Government by the Paperwork 
Reduction Act of 1980. This Act defines IRM as "...the planning, organizing, 
directing, training, promoting, controlling, and management activities associated 
with the burden, collection, creation, use and dissemination of information by 
agencies, and includes the management of information and related resources such 
as automatic data processing equipment.: To emphasize the importance of IRM in 
the Government, this Act requires the Senior Official in each agency to designate 
a DSO for IRM. (COMDTINST 5230.38, 30 May 90). 

The instruction then appoints the Chief, Office of Command, Control, and 

Communications (staff symbol and common shorthand reference: G-T), a Rear Admiral, 

as the Coast Guard's DSO for IRM. His responsibilities are described in broad terms. 




Further policy guidance is found in COMDTINST 5230.41, Information Resource 
Management. It recognizes the state of the existing suite of systems, then looks to the 
future: 

Most of our existing information systems were developed to meet individual 
program needs. This approach, while reasonable at the time, has led to many 
current management and information system problems, including those of 
conflicting, erroneous, and redundant data, and gaps between program-specific 
systems. The Coast Guard is fortunate because it now has a widely-developed 
infrastructure of standard information technology 1 , and this infrastructure is 
becoming more capable and better interconnected every day. It is now practical to 
use this infrastructure for developing cross-program or cross-functional information 
systems to enhance our mission effectiveness. 

... A CFS [Cross Functional System] is an information system that supports 
organizational processes relating the activities of several programs or functional 
divisions, rather than the activities of a single program. (COMDTINST 5230.41, 30 
May 90). 

Of special note in this instruction are several 1RM Principles: 

The following principles shall guide Coast Guard IRM. They establish the 
relationships between the IRM oversight and support roles of Commandant (G-T) 
and the direct IRM responsibilities of our major programs: 

a. IRM activities which support improving the way of doing business are 
preferred to those which simply automate or replace existing functions. 

b. Individual IRM solutions may be suboptimized for the greater good of the 
Coast Guard. 2 


'This standard technology (the CG Standard Workstation) is not always implemented in a 
standard fashion, however. This results in a good set of tools, but not quite yet a solid 
infrastructure. (Squires, 1991). 

2 This deceptively simple statement is arguably the most important and most difficult to 
achieve IRM policy. See chapter VI for a further consideration of the issues involved. 
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... d. All Coast Guard locations will be interconnected with integrated 
telecommunications facilities. 

e. Major organizational elements shall have direct IRM responsibilities. 

f. Commandant (G-T) has the dual roles of Coast Guard IRM oversight and C3I 
infrastructure support. 

... i. The Coast Guard will minimize data redundancy and multiple data entry 
activities. The ultimate goal is single point data entry. (COMDTTNST 5230.41, 

30 May 90). 

Finally, this instruction presents a rationale for implementing cross-functional 
systems, in a Coast Guard context. This will be expanded upon in Chapter IV, which 
discusses recent work in the field of organizational design and the increasingly critical 
role of information systems as a cornerstone of the successful organization. 

B. RECENT PAST IRM POLICY ATMOSPHERE 

The Coast Guard has not viewed information systems as a strategic tool for 
changing the way of doing business. In large part, the systems now in place serve simply 
to gather data, and perhaps do so in a slightly more efficient way than the paper-based 
systems they replaced. However, they are all independent systems, with no interaction 
between each other, and there is huge data redundancy. The data redundancy costs the 
Coast Guard significantly, in several ways: 

• In wasted time by field unit personnel who have to enter the same data into several 
independent systems, manually re-keying the data each time. 

• In storage and operations costs, since the data are maintained at several different 
sites around the country, each with dedicated personnel and equipment. 

• In data inconsistencies which result from the separately maintained databases. 
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Not all the existing systems collect their data more efficiently than the older systems 
they replaced. In the case of SARMIS, the computer-based system is widely felt by field 
personnel to require two or three times as long, per typical case, as the paper-based 
system it replaced (somewhat more data is collected, but not enough to account for all 
the difference. The awkward user interface is a major contributor to the problem.) 

This situation has prevailed until recently, mainly for two reasons. First, past 
information systems have been developed primarily by program managers, with little 
involvement from the IS professionals in the Coast Guard’s IRM division, G-TTC. 
(Decentralization advocates would argue that this is the best way to develop systems, and 
for most application systems, that is probably true. However, see Chapter VI for a 
discussion of two special cases: cross-functional systems and an organization-wide 
information architecture.) 

Second, G-TTC does not have sufficient authority (and is not in an organizational 
position) to oversee information systems initiatives. Accordingly, each has been 
developed from scratch by a different team acting without benefit of lessons learned from 
other projects and with little motivation to benefit the organization as a whole. To be 
fair, some program managers accuse G-TTC of not being responsive when approached 
about becoming involved in developing a new system. Regardless of the source of the 
problem, there remains the fact that not enough coordination has existed between the IRM 
overseer and the development staffs. 

Fortunately, it seems that this may change. Program managers see the benefits of 
integrated systems and parallel systems development, and are cooperating much more 
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closely in the generation of systems which are now in the planning stages. Top 
management has begun to give G-TTC more authority over systems development, partly 
by designating G-T as the "Designated Senior Official" for IRM. 

C. DATA COMMUNICATION IN SUPPORT OF IRM 

Almost all data entry for the information systems considered in this thesis is done 
on the standard workstation, then transmitted to the central database by one of several 
means. This section first describes the various data communications networks in use by 
the Coast Guard, then delineates the ways in which systems use them. 

1. Coast Guard Data Communication Networks 

a. AUTODIN: 

For record message traffic between the major nodes of its communication 
system, the Coast Guard uses the Department of Defense's Automatic Digital Network. 
Major Coast Guard communication centers (CGHQ, Areas, Districts, and CommStas, etc.) 
have AUTODIN drops, where they interface between this long-haul network and the 
other networks described below. 

b. SSAMPS and SW/SSAMPS 

Since the Coast Guard has AUTODIN drops at only a few major nodes, 
the Coast Guard has built its own networks for relaying record messages to smaller units. 
The networks that perform this job are called DISTNETs (below). The interface between 
AUTODIN and the DISTNETs is the Standard Semi-Automated Message Processing 
System (SSAMPS). Earlier versions of SSAMPS used special-purpose Hewlett-Packard 
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hardware at major nodes. A shift is underway to replace this hardware with general- 
purpose CG Standard Workstations (CGSW), giving rise to the new name SW/SSAMPS. 
This system is installed at the major nodes where AUTOIDIN drops are located, and 
interfaces between the Coast Guard and DOD networks. 

c. DISTNET 

The District Telecommunications Networks are distribution networks for 
record messages, used within a single district, and connected to SSAMPS. These 
networks are being converted from supporting record messages only to supporting general 
data transfer. Also, they are being converted from dedicated landlines to the new Hybrid 
Data Network (see below). 

d. HDN 

The Hybrid Data Network is a new system that will connect shore units. 
It will replace and consolidate several transmission services, including record messages, 
the independent network which supported MSIS, and several others. The HDN will allow 
three access methods for data transmission, providing flexible support to systems: 


• Dedicated X.25 service: dedicated, leased packet switched lines, 4800 to 9600 bps. 
Terminal equipment is on-line at all times. 

• Virtual Dedicated X.25 service: leased packet switched lines, 2400 bps. Terminal 
equipment appears on-line to the user, but is actually connected to a switched voice 
grade line when a connection is needed, and disconnected at other times. The 
network is able to "call" dedicated and virtual dedicated users. 

• Asynchronous dial access: users must dial the network themselves; the function is 
not automatic, as with virtual dedicated service. 
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These access methods obviously have important effects on the systems. 
The first is appearance to the user: if there is dedicated or virtual dedicated access, the 
user feels as if the system is right there, since he or she does not have to worry about 
establishing the connection to the remote site. With dial-up access, on the other hand, 
the user has in the past seen the separation between local and remote systems clearly (and 
perhaps painfully), since establishing the connection has been done manually. The dial¬ 
up function is now being built into application systems by their developers. These 
systems rely on dial-up access from low-volume users, but automate the connectivity 
task for them after a one-time setup by the local system operator. 

The second effect is timeliness. All three methods allow on-line updating 
and interactive querying of the host. However, the rapidity of on-line updates may not 
be necessary for some systems; it will be cheaper to save data until off-peak hours, and 
then transmit them in a batch. 

e. SprintNet 

This network, formerly called TeleNet, is operated by U.S. Sprint, and 
the Coast Guard (through an FAA contract) purchases data transmission services on it for 
the HDN (above). When the present contract expires on June 8, 1992, it will not be 
renewed; rather, services will be purchased from other carriers under the terms of GSA's 
new FTS2000 communications contract. Some hardware at Coast Guard sites is presently 
leased from Sprint along with the lines; this will be replaced with Coast Guard-owned 
equipment before the cutover date. 
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/. Electronic Mail 

The standard workstation supports electronic mail using Unisys’ B-Mail 
program. Each LAN constitutes a "mail center" (the exact configuration may vary 
somewhat), which is analogous to a post office. Large units with several LANs may have 
only a single mail center (a "capital" center) that serves all internal LANs. Messages can 
be sent to and from any user at any center, and any form of binary file can be "attached," 
allowing easy exchange of computer files. This system can also be used for record 
messages — SW/SSAMPS uses B-Mail as its transport mechanism. One drawback is 
that the system requires intensive involvement by local system administrators. 

g. ITDS 

The Information Transfer and Delivery System replaces the Message 
Transfer and Delivery System (MTDS), and integrates transmission of data and record 
messages between districts. It uses B-mail and the HDN. 

2. Information System Use of Networks 
a. SARM1S 

Until 1990, field units sent paper reports from SARMIS/DES (the Data 
Entry Subsystem) to their district offices, where they were keypunched by a DP staff into 
80-column card images. District staff members then performed manual data checking 
and validation. Validated records were transmitted to the SAR database at headquarters 
by Remote Job Entry (RJE). 
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A recent upgrade, SARMIS/DES version 1.2, allows field units to send 
their data to the district by mailing floppy disks, or as attachments to electronic mail 
messages. There, district staffs enter data into SARMIS/DSS, the District Sub-System. 
Transfer from districts to the SAR database will continue to be done via RJE, but will 
use the HDN as the transfer network when its RJE capability is functional. 

b. SIMSIELT and LEIS 

The original input mechanism for LEIS was SEER messages, manually 
prepared by field units and sent via SSAMPS and AUTODIN to the OCC in New York, 
where they were electronically scanned, checked, and entered in the database if valid. 
SIMS/ELT will prepare and send these messages automatically, and print a local copy of 
the message report. Alternately, the program can generate a report to be sent as an E- 
mail attachment (however, this mode is not yet suported at the OCC, so is not yet 
implementable). Data are transmitted directly to the central database, and are usually on¬ 
line within 24 to 48 hours. 

c. MSIS 

MSIS data are entered on-line by field users, in interactive sessions. The 
system has in the past used its own system of X.25 packet-switched lines, leased from 
SprintNet, but is transitioning to the Hybrid Data Network. Data are available to other 
users immediately after it they are entered. 






D. COAST GUARD STANDARD WORKSTATION 


In the early 1980's, when there was no clear choice of microcomputer and operating 
system 3 , the Coast Guard conducted a competitive procurement for a general purpose 
microcomputer contract. This procurement promoted standardization, prevented a 
proliferation of incompatible equipment, and was intended to provide the service with 
state of the art microcomputer capabilities, which could be readily expanded. (Maes, 
1987, p. 3). 

1. Hardware 

The hardware contract for the Coast Guard Standard Terminal, now called the 
Coast Guard Standard Workstation (CGSW), was originally awarded in June 1981 to C3, 
Incorporated, and called for fixed unit prices on equipment to be supplied in variable 
quantities, as commands needed the machine (Maes, 1987, p. 42). That contract was 
renewed several times, then recompeted and awarded to Unisys Corporation, which is 
presently the vendor for the CGSW. 

The machines purchased under the original contract and subsequent renewals 
are similar to the IBM PC and its progeny in that they are based on the Intel 80x86 
microprocessor series. However, the operating system, Unisys' BTOS (formerly CTOS), 
is different (see below). The growth in capabilities and numbers of personal computers 
at Coast Guard units has been similar to that in the rest of the business world. The 
CGSW has become an integral part of information use at every unit. 

^e dominant microcomputer operating system was CP/M, the IBM PC had not been 
introduced, and Apple was little-known. 


21 





2. Operating System 


The Convergent Technologies Operating System (CTOS) was capable of 
networking, unlike other microcomputer architectures. The only technology for shared 
computing resources available at the time was minicomputers or mainframes with multiple 
dumb terminals. C3 was at that time unique in offering the ability to network smart 
terminals and share system services without the overhead of a minicomputer. 

The operating system is based on a command language interface, similar to 
those in PC-DOS and basic Unix, with one exception: the user types in the command 
name, or any unique abbreviation thereof, presses <Retum>, and is then pres ,d with 
a fill-in form listing all possible parameters for that command, and indications of whether 
each parameter is required or optional. This is in contrast to DOS and Unix, wherein the 
user must type the command name and all parameters at once, and gets no prompting 
about parameters. The CTOS <Help> facility should be more meaningful, but for 
experienced users, like most system administrators are, this interface is very quick and 
easy to use. 

3. User Interface 

From a user interface point of view, the CGSW keyboard is significantly 
different from that of the IBM PC: there are dedicated keys for <Help>, <Finish>-ing 
applications, <Mark>-ing and <Bound>-ing text to be manipulated, and for scrolling text 
onscreen without changing the cursor's relative position. Dedicating and clearly labeling 
these keys makes it much easier for neophytes to learn applications, and for experienced 
users to use them, if the application software supports them well. For instance, if a user 





sees a key labelled <Help>, presses it, and gets a meaningful explanation of possible 
actions in the present context, then it has been successful. If the message is a general one 
and laden with computer jargon, then it fails to give the user the desired assistance. 

Just as in the DOS world, CTOS/BTOS application software has had no 
standard interface until recently, when a small amount of standardization has been 
achieved. Most CGSW applications now display "softkeys", or labels that apply to the 
ten function keys, across the bottom of the screen, either continually or on demand. In 
some applications, such as B-Mail and SIMS/ELT, these very effectively take the place 
of a menu, changing their meanings as different actions are taken. 
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III. EXISTING USCG OPERATIONAL INFORMATION SYSTEMS 


This chapter presents a picture of the state of Coast Guard information management 
by examining three existing operational information systems. The systems being 
considered were selected because they are used by a large proportion of Coast Guard 
units. Also, they represent a large part of the spectrum of decision types, supporting both 
tactical and strategic decisions. Sections A through C of this chapter describe in some 
detail the systems that support the Marine Safety, Law Enforcement, and Search and 
Rescue programs. Section D briefly describes some others, to lend the reader a sense of 
thr scope of Coast Guard information and the present attempts to manage it. 

A. MARINE SAFETY SYSTEMS 

The Marine Safety Information System (MSIS) supports the headquarters office of 
Marine Safety, Security, and Environmental Protection (G-M). A replacement system, 
the Marine Safety Network (MSN), is in the planning stages. 

1. System Background and Goals 

In 1974, the office of Merchant Marine Safety developed the Vessel Inspection 
Information System (VIIS). In 1977, the Office of Marine Environment and Systems 
developed the Port Safety Reporting System (PSRS), for tracking violation histories of 
vessels calling at U.S. ports. In 1984, the two were combined to form the Marine Safety 
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Information System. A Vessel Documentation module was added to the system in 1988. 
(COMDTINST M5230.llA, p. 1). 


The Marine Safety program has several responsibilities, including: inspection 
of vessels and facilities, documentation of vessels, licensing of maritime personnel, and 
protection of the marine environment. These are carried out by roughly 110 field units, 
including Marine Safety Offices (MSO's), Marine Inspection Offices (MIO's), Regional 
Examination Centers (REC's), and others. Because the vessels and people being regulated 
are highly mobile, a central clearinghouse for information about them is vital. MSIS 
serves as that central clearinghouse — an interactive central database that is updated 
frequently by field units. 

MSIS-supportcd decisions are both tactical ("should I inspect vessel XYZ 
when it enters port today?") and strategic (should the Coast Guard issue new tanker safety 
regulation AB1234?"). A secondary goal is to automate certain processes, as a time- and 
labor-saving tool. 

After more than a decade of evolution, MSIS is more thoroughly integrated 
into the daily routine of marine safety personnel than any other operational information 
system in the Coast Guard. It serves as a source of information and as the primary tool 
for reporting operations; it is an effective means of sharing information about vessels 
between the many MSO’s. This is not to say that it is completely well integrated; on the 
contrary, users still complain about some facets of the system. However, marine safety 
units could no longer perform their mission without MSIS, and it is the most heavily 
relied-upon operational system in use in the Coast Guard today. 


25 




2. User Interface 


MSIS is menu-driven, making it easy for users to leam and use. One 
shortcoming of the existing system is that the entire screen display, menus and all, is sent 
over the telecommunications link between host and user. This means that it can take 
several seconds to completely refresh a screen display, slowing the session down 
significantly. Also, the menu structure is organized with respect to the information 
products stored in the data tables, rather than by function or purpose. This means that 
users must be familiar with the structure of the database in order to retrieve information 
from it. (Wilder, 1991). 

3. Hardware, Software, and Telecommunications 

Field units use CGSW's and modems to link with the host. The CGSW's 
employ no processor power in the present system, but act as dumb terminals. The host 
is a network of Prime minicomputers at Batelle Labs, Columbus, Ohio. Batelle created 
the Automated Construction of Transaction Systems (ACTS), a rudimentary 4GL, to 
generate FORTRAN code for the application programs, and relies on Total, a relational 
DBMS, for the data base. (USCG Agency Procurement Request, 1991). 

4. Future development plans 

CGHQ (G-MIM) is designing a follow-on to MSIS, which will be called the 
Marine Safety Network. It will stress interaction with other systems, including LEIS II 
and external databases. It will be a distributed system, using the processing power of 
remote CGSW's, and have a graphical user interface. It will rely on the Hybrid Data 


26 






Network for transport. Hardware and software configurations are yet to be determined, 
but will be based on open systems architecture. This will include POSIX-compliant 
operating systems (Standard Portable Operating System Interface for Computer 
Environments, FTPS PUB 151), GOSIP-compliant communications architecture 
(Government Open Systems Interconnection Profile, FIPS PUB 146), and SQL- 
compatible (Structured Query Language, FIPS PUB 127) database management system. 
(USCG Agency Procurement Request for MSN, 1991). 

B. LAW ENFORCEMENT SYSTEMS 

The headquarters office of Defense Operations and Law Enforcement, Law 
Enforcement Division (G-OLE), is supported by a combination of three systems described 
below. A replacement system, the Law Enforcement Information System version II (LEIS 
II), is in the development stage. 

1. System Background and Goals 

Before the mid-1980's, there was no central Coast Guard database of law 
enforcement information. Information was reported by teletype message from operating 
units to their district commanders, who typically retained some sort of paper file. 
Districts typically had different reporting requirements, although there was some 
standardization within Atlantic Area and Pacific Area, respectively. When units operated 
outside their normal areas, they had to check manuals for the different reporting 
requirements and message formats. In the mid-1980's, the Coast Guard standardized law 
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enforcement reporting nation-wide. Operating units still submitted teletype messages, but 
now they were the same everywhere. 


The new law enforcement message system iss the Summary Enforcement Event 
Reporting System (SEER). The messages are computer-formatted, with strictly defined 
fields. The fields make up "Event Lines," each of which becomes a database record. 

The SEER messages are sent to operational commanders, and also to the 
Operations Computer Center in New York, where they are stored. The Law Enforcement 
Information System (LEIS) was then designed to allow program managers to retrieve 
information via modem connection from CGSW's. 

Finally, in 1988, the Shipboard Information System/Enforcement of laws and 
Treaties (SIMS/ELT) was introduced. It automates the preparation of SEER messages, 
and creates a local database for the field unit’s use. SIMS/ELT does not allow direct 
interaction or online updating of the LEIS database; it is strictly an input system. Input 
messages arrive at the OCC and are buffered, manually checked for errors, and then 
entered in batches. The input data can be available for retrieval in LEIS as soon as a few 
hours after the incident in the best case, but more typically between 24 and 48 hours later. 

The existing system was designed mostly for strategic decision making by 
program managers. It was not accessible to field units until April 1991 (COMDT 
COGARD MSG 011755Z APR 91), so tactical support was not provided. One limited 
exception is that units were able to gain some information through voice radio requests 
to group and district offices, but this method was cumbersome. 
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2. User Interface 


The LEIS interface is one of the most difficult among existing Coast Guard 
systems. Although a few menus are available, it consists primarily of a proprietary 
command line query language. Like all query languages, this one is extremely involved 
for the uninitiated. The Coast Guard operates week-long training sessions to indoctrinate 
users in LEIS, and most of the time is spent on the query language; however, because of 
the complexity of command-line languages in general, many still have trouble using all 
the capabilities of the system after completion of the school. LEIS supports information 
retrieval only; no on-line updating is allowed, since all input is via SEER or SIMS/ELT. 

The SIMS/ELT interface, in contrast, is probably the best among present Coast 
Guard systems, and therefore will be described in somewhat more detail. It is a clearly 
organized form-based system, and keeps users aware of their progress and the big picture 
throughout a session. A typical data entry screen, for an Identification Event Line, is 
shown in Figure 1. 

The form-based design of SIMS/ELT allows rapid data entry, in contrast to 
the SARMIS interface, which will be described in the next section. On-screen forms 
consist of several logically related data fields, and are rewritten only after a complete 
form is done, so users can move quickly between fields. Finally, it has a well- 
implemented on-line help function. A single press of the <Help> key brings up a box 
that describes the purpose and content of the record, or Event Line, currently being 
entered, and all fields within it. A second press yields a box with all valid codes for the 
present field. 
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I Enter data irt selected field 


L ”* Identification Line *** 


Event ID Patrol Nunber OPFAC 


Date (KMDD/TQ. 

HW 

Color Hull:SS... 

Detection ID. 

38 858858 

Vessel Neme_ 

Thie (ZULU. 1+Min) .. 

■B 

State nunber ... 

Vessel type. 

888888 

Radio Call Sign.. 
Official Doc#... 

Activity of Vessel. 

Suspicion Code. 

H 

Hull ID #. 

Main Beam # .... 

Boarding Code. 

Length (Ft or Mt). 

H 

Flag. 

Home Port. 


Figure 1: SIMS/ELT Identification Event Line data entry screen. 


The SEER and SIMS/ELT system is based on events. Each event type is 
described by a line of data, and each has a dedicated data capture screen. The nine event 
types defined by the system are: 

• OPAREA Employment 

• Position 

• Detection 

• Identification 

• Boarding 

• Violation 
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• Last/Next Port of Call 


• Crew 

• Remarks 

This organization of the reporting system into logical data records based on 
real-world occurrences makes it easy to understand and use. 

3. Hardware, Software, and Telecommunications 

SIMS/ELT runs on the CG Standard Workstation. LEIS runs on a PRIME 
9955 mod 2 minicomputer at the Operations Computer Center. 

LEIS was written in Primelnfo by the Department of Transportation's 
Transportation Systems Center (TSC) in 1985. It has been modified extensively by Coast 
Guard personnel since its implementation. The hardware and software will be moved to 
the Operations Systems Center in Martinsburg, West Virginia when that facility opens in 
1991. 

SIMS/ELT was written by the Coast Guard's Electronics Engineering Center 
(EECEN), Wildwood, NJ. It is written in Application Development System (ADS), a 4th 
generation, forms-oriented programming language, for use on the Coast Guard Standard 
Workstation. ADS includes DBMS functionality for maintaining the local data base. 

Data communications at present are by record message. SIMS/ELT supports 
E-mail transfers, but that option is not available at the OCC yet. In the former case, 
SEER messages are transmitted to the OCC as AUTODIN messages; this method usually 
uses SSAMPS from the unit to the district office, then either AUTODIN or ITDS to the 
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OCC. At the OCC, incoming SEER messages are scanned electronically into the batch 
update queue. Messages containing errors are marked for human intervention. In the 
latter case, SIMS/ELT sends SEER data as B-mail attachments. These are also collected 
in a batch queue. Since they are machine-prepared at the unit level, and SIMS/ELT 
employs validity checks, the error rate is much lower than for SEER messages, but a few 
are still rejected. 

4. Future development plans 

The follow-on system, LEIS II, has been designed, and coding will begin in 
mid-1991. The system will stress tactical decision support, with the goal of being 
available to field units with quick response times for board/no-board decisions. It will 
rely on a distributed architecture, with a central minicomputer as the server and remote 
CGSWs linked via various telecommunications channels. It will also stress open systems 
architecture, compliant with GOSIP, POSIX, and SOL. (System Resources Corp., 
8/20/90). 

C. SEARCH AND RESCUE SYSTEMS 

The headquarters office of Navigation Safety and Waterway Management, Search 
and Rescue Division (G-NRS), is supported by a combination of three systems. 
SARMIS/DES (Data Entry Subsystem) is used at the unit level for data entry. 
SARMIS/DSS (District Subsystem) is used at district offices for compiling a district-wide 
database and to prepare data for upload to the central database. The SAR database is the 
central, Coast Guard-wide database. 
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1. System Background and Goals 


For years, units submitted a SAR Assistance Report to CGHQ for every SAR 
case performed. The data was compiled in the SAR database, and used to justify budget 
requests and for strategic resource planning. Input remained in the form of the paper 
report, form CG-5151, until about 1986, when SARMIS/DES was implemented to 
automate the process and expand the amount of data collected. Finally, in 1989, 
SARMIS/DSS was developed, allowing district offices to compile their own district-wide 
databases and conduct error-checking before forwarding unit reports on to headquarters. 

As mentioned above, the primary purpose of the SAR database is strategic 
decision support. A secondary use of the SAR database is to provide density plots and 
other decision tools for district, group, and unit planners; however, this support is 
provided off-line, requires a written request via the chain of command, and takes several 
weeks, so usability is low. 

SARMIS/DES was designed to automate the data input process, and eliminate 
keypunching at headquarters. However, since it collects significantly more data than the 
old paper forms, users estimate that it takes roughly twice as long to document a case 
using the computer than it did with paper. The program provides the unit with a few 
pre-formatted monthly summary reports, but does not allow ad-hoc queries. 

SARMIS/DSS runs on CGSWs at the district offices, accepting input in the 
form of data from SARMIS/DES. It validates data, then uploads it to the SAR database 
using RJE. It also provides an interactive database, written in C and Progress, which can 
be used for ad-hoc queries about SAR incidents within the district. 
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2. User Interface 


The interface for the central SAR database is a command-line query language. 
However, there is no provision for remote access to the system by operating units. All 
requests for information are submitted to headquarters on paper, where a computer 
operator issues the database query and mails the report back to the requestor. 

SARMIS/DES is operated by field unit personnel, usually the boat coxswain 
or a watchstander who was involved in a particular case. It claims to be interactive, but 
is so only in the data entry module. There is no capability to query the local database 
in an ad-hoc fashion. Units simply get pre-formatted monthly summaries and electronic 
reports to send to the district office. SARMIS/DES typically asks the user one question 
per screen, then clears it and rewrites the next question. This design makes it easy to 
leam, but very slow in general use, since users must continually refocus on the new 
screen and re-orient themselves to the question being asked. It also prevents the user 
from retaining a feel for progress through the program — one quickly becomes lost in 
the maze of new screen displays. On-line help is limited; however, since each question 
is presented in such great detail on the primary data entry screen, this is not a terrible 
drawback. If a user is forced to stop data entry before a record is complete, there is no 
way to save what has been done so far, a serious drawback when data entry for each 
record takes from five to fifteen minutes. 

3. Hardware, Software, and Telecommunications 

The SAR database is hosted on an Amdahl mainframe computer at the 
Transportation Computer Center, Washington DC. The Coast Guard's access to the 
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database is through an asynchronous 1200 bps terminal in the offices of G-NRS, where 
a single GS-11 employee performs maintenance and issues queries. Ten years' data are 
stored online; that comprises roughly 700,000 records, approximately 150 megabytes. 
The program was written in the late 1970's by personnel at the Transportation Systems 
Center using Focus™, a relational DBMS. 

SARMIS/DSS and SARMIS/DES both run on the Coast Guard Standard 
Workstation. SARMIS/DSS is written in C and Progress, a fourth-generation language 
and DBMS. It was developed in 1989 by Ship Analytics, Incorporated, under contract 
to the Coast Guard Research and Development Center. SARMIS/DES is written in 
Pascal. It uses Direct Access Method (DAM) to access the data, not a DBMS. 

SARMIS/DES data can be sent to the district office by E-mail, record 
message, mailing floppy disks, or mailing paper reports. From the district office to 
headquarters, data is sent over a synchronous 9600 bps line, using RJE (remote job entry) 
software. 

G-NRS will shift to the Hybrid Data Network in late 1991, when the BTOS 
version of RJE has been modified to support the X.25 protocol. 

Mailing paper reports and floppy disks from units to the district is becoming 
increasingly rare, with most units using E-mail and a few using messages. 

4. Future development plans 

The SAR database has several shortcomings. It still uses only the limited set 
of data collected by the paper forms CG-5151 before 1986, not the full range of 
information collected by SARMIS/DES. It is the only application still using FOCUS at 
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the DOT computer center, and there is pressure from system operators there to migrate 
to another language, perhaps Oracle. 

SARMIS/DES will be rewritten soon to move away from Pascal and DAM, 
and into a DBMS that allows flexible queries locally. G-NRS is cooperating with G- 
OLE, G-OP, and the RDC to investigate a sortie-based data collection front end, which 
will collect data only once, then feed it to the systems that need it. It could use the 
Geographic Display Operations Computer (GDOC) system when that becomes 
operational. 

D. OTHER USCG INFORMATION SYSTEMS 

This section describes some of the Coast Guard's other information systems, to 
provide the reader a sense of the scope of Coast Guard information management. 

1. CASP 

Computer-Assisted Search Planning, or CASP, is more a computational 
program for modelling and planning maritime searches than an information system; the 
data entered by an operator are used only as inputs for the program to predict drift and 
search areas, and are normally not saved for review by program managers. It is an 
interactive, menu-driven program hosted on a PRIME 9955 minicomputer at the OCC. 
It will move to the OSC in Martinsburg, WV. 

2. AMVER 

Automated Mutual Assistance Vessel Rescue, or AMVER, is one of the oldest 
systems in use by the Coast Guard. It was developed in the mid-1960's, pursuant to 
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international search and rescue agreements, in order to track seagoing ships. These ships 
voluntarily submit sail plans, which are keypunched into a database in the PRIME 9955 
minicomputer at the OCC. The system is accessed by rescue coordinators and search 
planners, so that during a distress at sea they may quickly determine what vessels are 
nearby and radio them directly for assistance. A follow-on, AMVER 2, is under 
development, to provide better access and output. 

3. OTHER SYSTEMS 

There are many more systems in use or under development. Tables 2 and 3 
show those listed in the Coast Guard's IRM plan in July 1990. (source: COMDTPUB 
P5230.43, 18 Dec 90, pp. 19-21). 
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TABLE 2: USCG INFORMATION TYSTEMS. 


Acronym : 

STARS: 

DMPS: 

DAFIS: 

IMAGE: 

LUFS: 

AMIS: 

DIAS: 

FINAIDS: 

ASIS: 

ACMS: 

CEDS: 

BEST: 

CBMIS: 

MMS: 

SAIL: 

ULMS: 

NEDMIS: 

CAD: 

HSMIS: 

TMPS: 

Cl AMS: 

NIPS: 

HAZMAT: 

SHARKS: 

MADCAP: 

LAW: 

LDR: 

MSN: 

VIDS: 

AUXMIS: 

RBS: 

BRAINS: 

AMVER2: 

CASP: 

LOIS: 

BAMS: 

ATONIS: 

AAPS: 


System Description : 

TRACEN Petalurr- Student Tracking and Reporting System 

International Ice Pa ol Iceberg Data Mgmt and Prediction System 

Departmental Accounting and Financial Information System 

Information Systems Division Image System 

Large Unit Financial System 

Acquisition Management Information System 

District Interim Accounting System 

Headquarters Accounting System 

Aviation Supply and Inventory System 

Aviation Computerized maintenance System 

Civil Engineering Data System 

Base Engineering Support, Technical 

G-ELM's Configuration Based Management Information System 
Defense Logistics Materiel Management System 
G-ELM System for Automated Integrated Logistics 
Unit Logistics Management System 

Naval Engineering Division Management Information System 

Naval Engineering Division Computer-Assisted Design System 

Health Services Management Information System 

Tri-Service Micropharmacy System 

Clinic Automated Management System 

NonFederal Invoice Processing System 

Hazardous Material Information System 

Safety/Health/Accident Relational Key System 

Medical and Dental Clinic Automation Program 

Legal Automated Workstation 

Legal Document Research 

Marine Safety Network 

Vessel Identification and Documentation System 
Auxiliary Management Information System 
Recreational Boating Safety System 
Bridge Administration Information System 
Automated Mutual Assistance Vessel rescue System 
Computer Assisted Search Planning System 
LORAN-C Operations Information System 
Boat Administration and Management System 
Aids to Navigation Information System 
Automated Aid Positioning System 








TABLE 3: USCG INFORMATION SYSTEMS, CONTINUED. 


Acronym: 

System Description: 

ACMS: 

Aid Control and Monitoring System 

CAP: 

Computer Assisted Positioning 

ENMS: 

Electronic Notice to mariners System 

VTS H/G ABDS: 

VTS Houston/Galveston Automated Bright Display System 

SARSIM: 

Search and Rescue Simulation Model 

TECS: 

Treasury Enforcement Communications System 

JMIE: 

Joint Maritime Information Element 

SPI: 

Security Program Improvements 

EMIS: 

Enforcement Management Information System 

LEIS II: 

Law Enforcement Information System II 

ELT/SIMS: 

Enforcement of Laws and Treaties/Shipboard Info Mgmt System 

OPSTAT: 

Abstract of Operation Software 

SRA: 

Computer for Service Record Automation 

PMIS/JUMPS II: Personnel Mgmt Info System/Joint Uniform Military Pay System 

PDS: 

Personnel Decision System 

TRAVEL: 

Travel Claim Automation 

RIMS: 

Recruit Information Management System 

PXM: 

Exchange and Morale Systems 

PC SYSTEMS: 

Civilian Personnel Systems 

CIRMS: 

Classified Information Resource Management Support 

DRMIS: 

District Reserve Management Information System 

MOBSYS: 

Reserve Mobilization System 

COMDAC: 

Command, Display and Control System 

STC II: 

Shipboard Tactical Computer II 

NAVMACS: 

Naval Modular Automated Communication System 

IRIS: 

Incident reporting Information System 

AISS: 

Automated Information System Security 

CGSWOA: 

CG Standard Workstation Contract Office Automation 

DRS: 

USCG Data Repository System Project 

MAP: 

Minicomputer Acquisition Project 

CDB/EIS: 

Corporate Database / Executive Information System 

DIS: 

Distributed Information System 

DCS: 

Distributed Computing System 

GTC: 

Geographic Tactical Computer 

OIS: 

Operations Information Systems 

SATCOMM: 

Commercial Satellite Communications 

COMMSTA: 

Communications Station Automation 

HDN: 

Hybrid Data Network 
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E. SUMMARY 


The existing suite of systems are vertically oriented file processing systems which 
have generally been built piecemeal around processing data files that began as paper 
reports. They have evolved as stovepipes because they mirror the way the Coast Guard 
structures its program management. They provide little in the way of distribution of data 
among Coast Guard information users, and less in the way of manipulation. They are 
hard to learn, awkward to use, and sometimes painfully slow at transferring information. 

Recommendations for improving these systems are put forth in Chapter VII. But 
these improvements would be expensive — they strike at the very hearts of the systems. 
And increasing the standalone functionality of existing systems may have a lower payoff 
than taking the next step, integrating the systems and re-engineering our information 
flow. The next three chapters examine the benefits of cross-functional systems, and 
propose a system that would increase the information payoff. 
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IV. CROSS-FUNCTIONALITY: A THEORETICAL FOUNDATION 


The Coast Guard has recently begun focusing on cross-functional systems as key 
strategic elements for new development; the concept has quickly achieved buzzword 
status. Yet, as with any new buzzword, there is confusion about the concept of cross- 
functionality and exactly what constitutes a cross-functional system. 

This chapter examines the conceptual basis for cross-functionality, beginning with 
a discussion of organizational structure: the need to organize, structures that have proven 
effective, and some of the problems inherent in organizing. The hierarchical and matrix 
structures are described. Discussion then turns to minimizing the limitations of these 
structural forms by establishing cross-functional organizational links, and means of 
supporting such a structure through information technology. Finally, a methodology for 
conducting the strategic MIS planning needed to achieve such a complex goal is 
reviewed. Chapter V will propose a cross-functional Operations Information System for 
the Coast Guard, relying on this theoretical framework. 

A. THE NEED TO ORGANIZE 

Simply put, human organizations have become far too large and complex to be 
understood, analyzed, and controlled in their monolithic entirety. Systems theory provides 
a convenient tool for breaking these huge entities down into manageable chunks. (Emery, 
1987, p. 241). 
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1. A Systems Theory Approach 

A large system has several subsystems, each of which has its own subsystems, 
until the activity at hand is reduced to a manageable level, typically something that can 
be performed by an individual or small group of individuals. Each subsystem is 
responsible for a certain portion of the overall goals, and the functions carried out within 
it are closely related to one another, at least as compared to other functions at that same 
level of organization. 

Each system has a boundary, which defines the activities considered to be 
integral parts thereof. Things outside that boundary are part of its environment; things 
that cross the boundary of the system under consideration are its inputs and outputs. 
(Emery, 1987, p. 241). 

As the number of subsystems 
within an organization grows, so do the 
number of interactions, or actions that 
cross subsystem boundaries. There are 
two primary sources of interaction: 
coupling and shared resources (see 
Figure 2). In coupling, the output of one subsystem is an input to another, so that any 
change in the output rate, quality, or other parameters from the first will impact the 
second. The same is true of shared resources, with the additional complication that the 
output from the first subsystem is used by more than one downstream subsystem. The 
output of the first is a resource, shared between the others; like any other resource, a 



Figure 2: System interactions (after Emery, 
1987). 
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scarcity produces tough decisions for the people who allocate it. If one of the 
downstream subsystems is considered more important than the other, it may get a 
proportionally larger share of the reduced resource; however, this creates even more 
problems if the process moves through other subsystems further downstream, in a domino 
or ripple effect. (Emery, 1987, pp. 243-44). 

The first way to reduce the number of interactions, and therefore the degree 
of complexity, is to structure the organization so that work groups (subsystems) are 
responsible for closely-related tasks. If this is the case, each can cope with as many 
things as possible internally. In a similar fashion, closely-related work groups should be 
clustered together. Then, if a certain task cannot be completed within the subsystem, it 
can likely still be handled with a minimum number of interactions by merely passing it 
up one level, or horizontally to a related subsystem. This technique focuses on 
eliminating interactions altogether where possible. 


Absent the ability to avoid 

interactions by structural means, as 

0 - 

I Decoupling 1 

J Technique | 

<B) 

above, one can at least mitigate their 
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effects through decoupling. Decoupling 

increases the isolation of a subsystem, 


L Buffer 

2 . Slack Capacity 
S. Standardization 



thereby reducing the frequency or FI S ure 3: , Techniques for decoupling 

systems. (After Emery, 1987). 


duration of interactions. There are 

several techniques for accomplishing this, as illustrated in Figure 3. One common 
technique is a buffer, which collects the outputs of the first subsystem until the second 
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is ready to receive them as inputs. Another is building systems with slack capacity, so 
that the rate of output can be adjusted depending on downstream demand or upstream 
supply. Finally, one can increase standardization. The consuming system decides under 
what range of conditions it can operate; if the output from the first system is within the 
specified limits of tolerance (whether these limits apply to rate, quality, or some other 
parameter), then the subunits do not need to coordinate. Only when there is an out-of¬ 
tolerance condition does coordination become necessary. (Emery, 1987, p. 249). 

Interactions due to shared resources are a harder problem than those due to 
coupling. One of the best ways of reducing these interactions is through the use of slack 
capacity, despite its cost. 

When the organization has exhausted ways of reducing the number and 
complexity of interactions, it must employ a coordination mechanism. This may be a 
human manager, or a process control computer; in either case, the task is to coordinate 
the interactions between the various subsystems. This may involve resource allocation 
decisions for subsystems, flow control, or responding to out-of-tolerance situations. 
Highly coordinated systems are often referred to as tightly integrated, and are 
characterized by tightly scheduled inputs and outputs, with extensive resource sharing. 
This has the advantage of greater efficiency for the system as a whole, allowing it to 
operate with fewer buffers and less slack capacity. Economies of scale may be realized. 
Perhaps most important, decisions can be made from the larger perspective of the system 
as a whole (or that of a larger set of subsystems), rather than from the perhaps suboptimal 
perspective of a smaller unit. 
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The problem of highly coordinated systems is that they are more complex, 
involving extensive interactions between subsystems. The benefits of integration versus 
independence must be weighed for the situation at hand, and an appropriate point along 
the spectrum from one end to the other chosen. Managers are now able to factor into this 
decision the fact that information technology, if properly applied, can simplify 
coordination. 

2. An Information Processing Approach 

Galbraith has described organization design principles from a point of view 
centered around the need to process information: 

If the task is well understood prior to performing it, much of the activity can be 
preplanned. If it is not understood, then during the actual task execution more 
knowledge is acquired which leads to changes in resource allocations, schedules, 
and priorities. All these changes require information processing during task 
performance. Therefore the greater the task uncertainty, the greater the amount of 
information that must be processed among decision makers during task execution 
in order to achieve a given level of performance. (Galbraith, 1974). 

In developing his analysis of the organization's structure, Galbraith presents 
a model (reproduced in Figure 4) which shows seven methods for coping with the need 
to process information, broken down into three categories. First are those which reduce 
the need to process information in relatively small organizations. Second, and quite 
similar, are methods to reduce the need to process information as the organization grows 
increasingly large and complex. Third are methods to increase the ability of the 
organization and its subunits to process information. Notice that the first two of these 
methods correspond closely to the systems theorists' approach of increasing independence 
of subunits, while the third corresponds to increased integration. 
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Galbraith's methods 6 and 7 


are the areas where information systems 
can greatly benefit the organization. 

Sharing information vertically and 
horizontally throughout the organization 
becomes feasible if, for example, all 
departments have access to a common 
database. In a mail order firm, a 
database with customer, order, and 

Figure 4: Organizational design strategies 
supplier information could be integrated (after Galbraith, 1974). 

across all functions so that order¬ 
processing clerks, packing and shipping clerks, billing clerks, and customer service clerks 
could all have access to the same information. Any of these people would be able to 
immediately get necessary, current information on the status of a customer or and order. 

B. COMMON ORGANIZATIONAL STRUCTURES 

What organizational structures have evolved from this theory? In this section, brief 
descriptions of two broad categories are presented. The descriptions are of general 
concepts of the structures, not specific implementation details, and are presented as an 
introduction to the concept of cross-functionality. 
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1. The Hierarchy 


Since the 1920's, when Alfred Sloan refined the model at General Motors, the 
functional hierarchy has been the most common structure in Western organizations 
(Norton, 1988). It is easy to understand, and embodies the span of control concept. It 
provides clear singularity of supervision (or command). Finally, it fits well with both the 
systems theory and information processing views of organization design: as tasks become 
increasingly specialized, they are moved to lower levels of the pyramid; higher levels 
coordinate between similar but distinct sub-units. 

However, a major drawback is that hierarchical organizations can have their 
major divisions organized along only one of several possible dimensions, such as 
function, product, market, or geographical territory. Figure 5 shows a typical functional 
organization, with its major divisions structured about the tasks people perform, or the 
inputs to the work process. 



Figure 5: Hierarchical organization structure (after Galbraith, 1974). 
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2. The Matrix 


The one-dimensional nature of the hierarchy has led several researchers to 
suggest alternatives, including the matrix organization. In this scheme, sub-units are 
organized along two dimensions at once; commonly these reflect the inputs to the work 
process (functional specialties) and the outputs (products). An example is shown in 
Figure 6. This firm has chosen to give primary control to managers in the functional 
dimension; other firms, with a more product-oriented culture, may reverse the roles. 



Formal authority over the product 
Technical authority over the product 


Figure 6: Matrix organization structure (after Galbraith, 1974). 
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3. Limitations of the Hierarchy and the Matrix 

In their popular book, In Search of Excellence, Peters and Waterman survey 
many U.S. businesses, striving to find out what sets the most successful ones apart. 
Among the eight attributes they ascribe to an excellent organization is one with special 
significance for this discussion — "Simple form, lean staff:" 

Along with bigness comes complexity, unfortunately. And most big companies 
respond to complexity in kind, by designing complex systems and structures. Then 
they hire more people to keep track of all that complexity, and that's where the 
mistake begins.... making an organization work has everything to do with keeping 
things understandable for the tens or hundreds of thousands who must make things 
happen. And that means keeping things simple. (Peters and Waterman, 1982). 

The essence of simplicity, they say, is picking one of the several dimensions 
described earlier and making it the primary focus of the structure; they prefer product, 
because it naturally relates everything the division is trying to accomplish. The thing to 
avoid is a complex, intertwined structure, such as a matrix, where each employee has two 
(or more) bosses, and no clear picture of who's in charge today. They do not advocate 
abolition of the matrix structure, but point out that those corporations which have 
implemented it successfully all specify clearly which dimension of the matrix is the 
primary one. This reduces the potential for ambiguity and anarchy. 

However, the need to keep things simple so that employees can cope with the 
size of the organization is only one side of the coin. On the other is the fact that 
functionally organized units frequently need to send information outside their own 
function, or branch of the hierarchy. Norton defines the building blocks of organizations 
this way: 
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An activity is the basic element of organized work.... A process is a collection 
of activities that are linked together, adding value by converting fundamental 
resources to achieve organizational objectives....A function is a collection of 
activities that are organized together by a common discipline.... Processes are the 
means by which organizations act to accomplish their objectives. Functions are the 
way organizations group people to achieve the benefits of specialization. As long 
as processes are intrafunctional, management is relatively straightforward. 
However, when function and process do not coincide, we create unnatural barriers 
to organizational effectiveness. (Norton, 1988). 


C. CROSS-FUNCTIONAL ORGANIZATIONAL STRUCTURE 

The limitations of a rigid hierarchy have led Norton and others to propose a cross¬ 
functional approach to organizing. The concept focuses on analyzing work and 
information flows (Norton's processes ) on the front line. It is similar to a product- 
oriented hierarchy, which emphasizes the organization's outputs ; however, it goes a step 
further, focusing on enabling the front-line worker to handle all aspects of a work 
activity. Cross-functionality occurs when a single organizational unit has responsibility 
for more than one function. A classic case in which cross-functionality would yield 
dramatic improvements involves a bank with several functional departments: 

A large midwestem bank has several independent business units, each of which 
maintains its own customer information files and "guards them religiously." 
Customers with multiple transactions cannot get a consolidated statement. Further, 
the bank has no idea of its overall exposure to any particular customer, no idea of 
its overall profitability by customer, no way to truly segment its market, no way to 
cross-sell its services. (Index Group, 1990) 

The quoted article points out the benefits that would be achieved by building a 
cross-functional information system: all departments would have access to the same 
information, top management would have access to consolidated information, and 
customers would perceive a logical, cohesive entity. This case is illustrated in Figure 7. 
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Figure 7: Banking example of cross-functional information system. 


In this case, the bank has two options regarding the extent to which it employs 
cross-functionality. First, it could leave things at the level cited, integrating the 
information system but retaining its previous structure (loan department, savings 
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department, etc). Second, it could redesign not only the IS, but also its structure. This 
concept is examined further in the next case. 

Where the activity involves the customer, cross-functionality can be especially 
important, in the interest of presenting a single face to the customer. By creating an 
individual position, or at least a small business unit, to be able to respond fully to a 
customer's query, some companies have achieved enormous advantages. Here is a real- 
world example: 

Mutual Benefit Life, the country's 18th largest life carrier, has reengineered its 
processing of insurance applications. Prior to this, MBL handled customers' 
applications much as its competitors did. The long, multistep process involved 
credit checking, quoting, rating, underwriting, and so on An application would 
have to go through as many as 30 discrete steps, spanning five departments and 
involving 19 people. At the very best, MBL could process an application in 24 
hours, but more typical turn-arounds ranged from 5 to 25 days — most of the time 
spent passing information from one department to the next (emphasis added). 
(Another insurer estimated that while an application spent 22 days in process, it was 
actually worked on for just 17 minutes.) 

MBL's rigid, sequential process le^ to many complications. For instance, when 
a customer wanted to cash in an existing policy and purchase a new one, the old 
business department first had to authorize the treasury department to issue a check 
made payable to MBL. The check would then accompany the paperwork to the 
new business department. 

The president of MBL, intent on improving customer service, decided that this 
nonsense had to stop and demanded a 60% improvement in productivity. It was 
clear that such an ambitious goal required more than tinkering with an existing 
process. Strong measures were in order, and the management team assigned to the 
task looked to technology as a means of achieving them. The team realized that 
shared databases and computer networks could make many different kinds of 
information available to a single person, while expert systems could help people 
with limited experience make sound decisions. Applying these insights led to a 
new approach to the application-handling process, one with wide organizational 
implications and little resemblance to the old way of doing business. 
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MBL swept away existing job definitions and created a new position called a 
case manager. Case managers have total responsibility for an application from the 
time it is received until a policy is issued. Unlike clerks, who performed a fixed 
task repeatedly under the watchful gaze of a supervisor, case managers work 
autonomously. No more handoffs of files and responsibility, no more shuffling of 
customer inquiries.... MBL can now process an application in as little as four 
hours, and average turnaround takes only two to five days.... case managers can 
handle more than twice the volume of new applications the company could 
previously process. (Hammer, 1990). 




Figure 8: Insurance company example of cross-functional system plus 
business reengineering. 
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In the banking example cited earlier, top management limited its application of the 
cross-functional concept to the information system. They used information technology 
as a means of enabling better integration between the business units, as in Galbraith's 
method 6, but retained the existing structure. The life insurance case, on the other hand, 
is an example of the concept of cross-functionality applied not merely to the information 
system, but also to the very structure of the organization. The restructured company is 
sketched in Figure 8. Hammer describes this further step as "business re-engineering:" 

It is time to stop paving the cow paths. Instead of embedding outdated processes 
in silicon and software, we should "reengineer" our businesses: use the power of 
modem information technology to radically redesign our business processes in order 
to achieve dramatic improvements in their performance. (Hammer, 1990). 

One can also analyze an organization from the viewpoint of the independent- 
integrated spectrum of organizational "tightness." On the face of it, one would expect to 
call a company with a high degree of integration between business units cross-functional, 
and one with high independence would not be considered cross-functional. Yet, as 
shown in the case of the bank, a cross-functional information system can provide the 
interface that allows independent units to act in a cross-functional manner, despite 
geographic or functional separation. 

D. STRATEGIC PLANNING FOR CROSS-FUNCTIONAL SYSTEMS 

Cross-functionality, whether applied merely to the IS or to the very structure of the 
organization, will require a level of planning beyond that required for more traditional 
applications. Yet this does not imply tighter control of application development, nor even 
more formal and rigid project management disciplines. The planning most needed is top 
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management vision about ways in which the organization can gain a strategic competitive 
advantage (in the case of the private sector firm) or provide dramatically improved 
services to the taxpayer (in the case of the public sector agency). 

James Wetherbe, at the University of Minnesota's MIS Research Center, has 
proposed a model for this process that helps management describe the key needs of the 
organization (Wetherbe, 1984). His four-stage-model, along with a fifth stage added by 
James Emery (Step 2, architecture; Emery, 1991), is described in the next sections of this 
chapter and illustrated in Figure 9. The resultant combination is used as the basis for an 
analysis of the Coast Guard's operational information flow in the next chapter. 


Wetherbe's 4-stage MIS Planning Model 



Emery's 5-stage MIS Planning Model Adaptation 
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Figure 9: Strategic MIS planning (after Wetherbe, 1984, and Emery, 
1991). 
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The IS plan must of course be 
linked to the overall business plan. Most 
organizations have some sort of formal 
planning process in which top 
management sets out a vision and broad 
directional guidelines. Lower level 
managers then generate more detailed 
plans for achieving these goals in their 
own functional areas. There is one potential difference with the IS plan: since 
information technology offers the potential to redesign the very structure of the 
organization, strategic IS planning may need to come before the general business plan, 
and the two will be involved in an iterative process. These relationships are described 
in Figure 10. 

1. Stage 1: Strategic MIS Planning 

The method Wetherbe employs for strategic planning is Strategy Set 
Transformation (King, 1979). It is designed to provide a direct link to overall 
organizational strategic planning. 

The outputs from the first stage include: 

• an accurate perception of the strategic aspirations and directions of the organization; 

• a new or revised MIS charter; 

• an assessment of the state of the MIS function; 


Strategic Business Plan 
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Figure 10: Business plan linkage with IS p 
lan and other supporting plans. 
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• and a statement of policies, objectives, and strategies for the MIS effort. 

This stage is carried out on an infrequent, as-needed basis, perhaps only once 
in a few years. Later stages will provide the year-to-year detailed plans. 

2. Stage 2: Information Architecture 

Wetherbe addresses long-range information architecture as a part of his next 
stage, Organizational Information Requirements Analysis. Emery prefers to break it out 
as a stage of its own, as outlined herein. (Emery, 1991). The architecture is of critical 
importance because, properly implemented, it serves a tremendous role as an enabling 
infrastructure. Just as a transportation system of waterways, railways and highways 
provide an enabling infrastructure for firms and citizens to carry out free enterprise 
throughout the nation and world, an information architecture provides the enabling 
infrastructure for exploitation of information technology. The three key components of 
the architecture are: 

• An organization-wide telecommunications network; 

• A shared database; 

• A common user interface. 

These components, once established, provide outstanding benefits, both for 
systems that use them and for future systems development within the organization. First, 
a robust network allows easy connectivity. Users can communicate with the central 
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database and with each other in a transparent way, independent of time differences and 
geographical separation. 


Second, the common database allows users and management to retrieve 
information in ways that simply weren't possible before (witness the banking example 
cited earlier in this chapter). Information from other functional areas, rather than being 
jealously guarded by individual departments, would be available to enable better decision 
making in all functional units. 

Third, and perhaps most commonly overlooked, is the common user interface. 
This allows users to gain immediate productivity, without a steep learning curve. This 
aspect has been one of the weakest points of many systems: program logic may be 
excellent, but an awkward interface discourages users from spending the time necessary 
to learn how to use it. 

Fourth, and perhaps most important for the organization’s long-term 
information processing needs, is the ease with which new applications can be develc ed 
after this enabling infrastructure is in place. A substantial portion of the complexity and 
cost of new applications goes to the three areas included in the infrastructure — 
communications, data management, and interface. By some estimates, the user interface 
alone counts for 70% of the lines of code in microcomputer applications. This 
percentage is certainly lower for minicomputer or mainframe applications, but even in this 
environment the interface accounts for an increasingly large portion of system resources. 
Given the success of the Macintosh interface described in the previous section, it is 
arguable that the interface on mainframe applications should account for a large portion 
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of complexity. At any rate, if these services are provided by the infrastructure, developers 
are free to concentrate on program logic, allowing them to deliver systems much more 
quickly and at substantially lower cost. 

3. Stage 3: Organizational Information Requirements Analysis 

This stage involves a macro-level analysis of the information needed to support 
the strategic plan. It should not be confused with the requirements analysis for a specific 
application project, which includes such detail as report formats and display design. 
Rather, it constitutes a statement of the key information needed in various parts of the 
organization, its sources and sinks. Identifying cross-functional information flows (and 
potential ones) is of special importance here. This stage is repeated annually during the 
planning cycle. 

4. Stage 4: Resource Allocation 

It is difficult to allocate scarce "resources among competing organizational 
units," especially if the "portfolio of potential applications does not fit into an overall 
organizational plan." (Wetherbe, 1984). The goal of this stage, therefore, is to carry out 
resource allocation in a rational way, based on the foregoing, higher level plans. 
Wetherbe lists several well-known methods for allocating resources in a systematic way: 
return on investment (ROI), zero-based budgeting (ZBB), and chargeout. Each of these 
provides a structured decision making methodology for prioritizing individual 
application development projects, and allocating fiscal and personnel resources. Each is 
also based on estimating the monetary value of the costs and benefits associated 
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with a project. However, estimating costs and benefits of information systems is 
notoriously difficult, so another method is proposed. 

A method not included in 
Wetherbe's work, but which can provide 
a valuable analysis of projects based on 
their respective risks, is a model 
proposed by McFarlan, McKenney, and 
Pybum (1982) of technical risk versus 
organizational and structural 4 risk. This 
is worth describing because of its 
explicit categorization of risks associated 
with projects; it will be used in the next chapter for analyzing risks of various proposals 
for Coast Guard systems. The model is depicted in Figure 11. The vertical axis 
represents organizational and structural risks, and the horizontal axis technical risk. 
Examples of systems are placed in the appropriate quadrants. 

5. Stage 5: Project Planning 

The final stage is concerned with developing individual systems on time and 
within budget. Techniques for this stage include the traditional system development 
process and various competing methods. Some tools that help manage the project include 
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Figure 11: McFarlan's risk 
model (McFarlan, 1982). 


assessment 


4 Organizational and structural risk involves resistance to change, political ramifications of the 
information flow in the organization, and the power represented in control of information. All 
these combine to form a very subtle, yet complex and deeply rooted set of factors to consider 
in this regard. 
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PERT, Gantt charts, and Milestones. A great deal of work is being done on minimizing 
problems of system development, and there are significant developments being made. 
The interested reader will find several articles and books devoted to this topic in the 
Bibliography. 

E. SUMMARY 

The concept of cross-functionality offers significant benefits to organizations. It 
is primarily aimed at increasing the ability of the organization to process information. 
The organization can achieve gains by exploiting this improved information flow within 
existing structures, or can use the technology as a driving force for business reengineering 
within the organization. 
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V. A CROSS-FUNCTIONAL OPERATIONS INFORMATION SYSTEM 


This chapter proposes a Coast Guard cross-functional Operations Information 
System (OIS), built on the theoretical foundation of Chapter IV. The primary focus is on 
stage 2, the information architecture, and stage 3, the organizational information 
requirements analysis. A robust information architecture offers great benefits by 
increasing the availability of information to those who need it, and at the same time 
decreasing the complexity involved in developing new systems. By analyzing 
organizational information requirements, it is possible to reengineer the flow of 
operational information in the Coast Guard, dramatically improving information 
availability. 

The proposal is followed by an anecdotal description of an incident using the 
present information flow, contrasted with a description of an incident using the envisioned 
information flow. 

A. STAGE 1: STRATEGIC MIS PLANNING 

This stage provides the linkage between the strategic organizational plan and the 
information systems function. This has already been performed by senior management, 
as discussed in Chapter II. The results of this linkage are framed in the terms of this 


model below: 





• Strategic aspirations and directions of the organization are taken from the 
Commandant's Strategic Agenda (COMDTINST 16000.21, 21 Sep 90). They are 
to prevent loss of life, damage to property, and damage to the environment; and to 
promote safe navigation on the nation's waterways and by vessels of this nation 
throughout the world. 

• The charter specific to MIS in the Strategic Agenda is "to increase efficiency and 
enhance capability through Information Resource Management." (COMDTINST 
16000.21, 21 Sep 90). 

• A general guideline which has significant application in the MIS arena is: "Acquire 
standardized equipment which improves interoperability with other agencies and is 
fully supportable within Coast Guard or other federal government resources." 
(COMDTINST 16000.21, 21 Sep 90). 

• The state of the MIS function is discussed at length in Chapter III of this thesis. 
To summarize, there are on the order of 100 separate information systems in use 
in the Coast Guard, with almost none sharing a common database. There is some 
use of common communication networks, and improvements ire being made. There 
is almost no commonality among user interfaces. Several major systems are 
undergoing significant enhancements, and a concerted effort is being made to 
encourage cross-functionality in those efforts. 

• Commandant Instruction 5230.41, Information Resources Management, describes 
policies, objectives, and strategies which guide the MIS effort. Those are listed in 
Chapter II. 


The sum of the guidance in these policies is clear: the Coast Guard is dedicated to 
improving its effectiveness through better use of information. There is a mandate to 
move toward cross-functional systems. 


B. STAGE 2: INFORMATION ARCHITECTURE 

The enabling role of the information architecture cannnot be overstated. With a 
solid infrastructure as foundation, development of individual systems becomes much 
simpler. The availability of a common network and user interface mean that developers 
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will not have to expend significant resources on those components, but simply implement 
the existing infrastructure components in the new system. The common database is the 
most demanding of the three infrastructure components: not only must the initial database 
be planned carefully, but subsequent addition of new systems will require careful data 
modelling to fit the database schema. 

1. Telecommunications Network 

The Hybrid Data Network (HDN) is the Coast Guard's shore-based 
telecommunications network. It presently provides dedicated or virtual dedicated 
interconnection to most major shore units, and will expand to serve all shore units with 
at least dial-up access by 1992. It has been implemented as the transport mechanism for 
SARMIS and MSIS. 

In order to provide connectivity with mobile units, the HDN must be 
augmented by establishing radio-based networks that connect with the HDN at key nodes, 
such as Communication Stations and Group Communications Centers. Several 
technological options for this are being explored, but none has been selected for 
deployment yet. 

HDN traffic should be prioritized, much as AUTODIN traffic is sorted by four 
classes of precedence. Time-critical traffic, such as information to support board/no¬ 
board decisions in law enforcement cases, would preempt most other types. 

In order to support the improved information flow that will be proposed, the 
radio network will need to support transmission of small bursts of time-critical data at 
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sporadic intervals. This requirement points to packet-switching as the solution, and 
meshes well with the HDN since it uses the X.25 packet transmission scheme. 

2. Common Database 

This component of the information architecture is less well developed, but it 
has received some attention. First, the Coast Guard uses Federal Information Processing 
Standards, which require database management systems that support the SQL standard. 
(FIPS PUB 127). Program managers developing new applications are encouraged to use 
either Progress™ or Oracle™ as the DBMS, by including these two products in the 
Standard Workstation contract for ease of procurement. Use of any DBMS, especially 
a common one, will be a vast improvement over the reliance of most current systems on 
file processing. Second, the Coast Guard has completed a set of Data Element Naming 
Conventions (DENC), designed to provide a foundation for achieving greater homogeneity 
between databases in future developments. 

Developing the common database, while certainly not a simple task, need 
not be considered impossibly complex. From a high-level point of view, there are only 
a few distinct objects about which the Coast Guard tracks information: vessels, people, 
and various types of incidents or characteristics involving them (law enforcement 
boarding, SAR case, licence number, etc.). With a concerted effort to achieve 
commonality, and strict application of the the Data Element Naming Conventions, a 
shared database can be created and new systems can be built to take advantage of it. 
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To illustrate this point, consider the cross-functional prototype system 


described in Appendix B. That system illustrates two things: 


• That cross-functional systems for the Coast Guard are technically quite feasible. 
This is evidenced by the limited resources that went into the project. Only about 
150 hours of effort (one person-month), from two people with no prior formal 
experience in database, produced a working microcomputer-based prototype system. 
It is certainly not a production-quality system, but if such a limited effort can 
produce a cross-functional system, surely a professional effort can yield effective 
operational systems. 

• That there is a large degree of redundancy of data across the SAR and ELT mission 
areas. The tables below summarize the data elements found to be common to both 
mission areas in this prototype. 5 


Tables 4 and 5 summarize the TABLE 4: REDUNDANCY SUMMARY. 


data redundancy found between the SAR 
Unit Case Folder and the Report of 
Boarding. Most costly in terms of time 
and frustration is the fact that field level 
personnel have to key in the same data 
to several systems. Also, the Coast 
Guard pays a heavy toll for the inability to correlate information contained in the 
independent systems. Finally, there aie the problems of data inconsistency across 
applications and of redundant mass storage at computing facilities. 


Data 

Element 

Type: 

Number 

of 

Items: 

Percent 

of 

Total: 

SAR 

10 

7.6 

ELT 

19 

14.4 

Common 

103 

780 I 


5 A caveat is necessary: the data requirements for this project were not taken from SARMIS 
and SIMS/ELT, but from the less detailed SAR Unit Case Folder (form CG-16130) and Report 
of Boarding (form CG-4100). The data requirements for the two computerized systems would 
undoubtedly show less redundancy, but the concept is valid. 
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At first thought, it seems 


TABLE 5: OBJECT DETAILS. 


incredible that nearly 80% of the data in 
the two systems is the same. However, 
when one thinks about the type of 
information the Coast Guard collects in 
terms of data objects, the reason for the 
overlap becomes clear. The Coast Guard 
only collects data about a limited number 
of real-world objects (people, boats, 
airplanes, etc), yet we collect it in several independent systems that were developed as 
stovepipes to support vertically-oriented functional program management. Further, it 
should be noted that this comparison reflects only two systems. If it had included others, 
it would likely have found a few more distinct data fields but a large number of common 
ones. 

Appendix B describes the real-world objects that must be represented in a 
cross-functional database such as this, and depicts their transformation into the relations 
and relationships of the database schema. 

3. Common User Interface 

In this arena, there is great room for improvement, as described in Chapter III. 
In one positive move. Unisys, the CGSW vendor, has initiated two efforts to bring 
improved interfaces to BTOS. First, the company is implementing an Applications 
Programming Interface (API) called XVT (Extensible Virtual Terminal). Applications 


Object: 

Data 

Elements: 

# of 
Tables: 

Incident 

24 

3 

Weather 

20 

1 

Person 

25 

2 

Vessel 

34 

1 

SAR Case 

10 

2 

Boarding 

19 

4 

Total 

132 

13 
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written to XVT can be ported to any of several graphical operating environments, 
including Macintosh, Presentation Manager, Motif, and Windows. It has distributed 
development toolkits to firms who write software for the BTOS environment, and the first 
of those new applications have been released. Second, the company plans to support 
Microsoft's Presentation Manager™ in future BTOS releases. 

These standards will provide applications with a similar "look and feel." If 
well implemented, they will also provide the ease of learning and use that was described 
in Chapter IV. These will dramatically decrease the time spent on training to use the 
systems, and increase the range of functionality available to users. 

C. STAGE 3: ORGANIZATIONAL INFORMATION REQUIREMENTS 
ANALYSIS 

In this stage, a macro-level analysis of information flows, along with sources and 
sinks, is conducted. It focuses on key information needed in various parts of the 
organization, and its sources and sinks. Identifying cross-functional information flows 
(and potential ones) is of special importance. 

The analysis begins with a deceptively simple question: why transfer information 
from one place to another in the first place? Before analyzing present information flows 
and proposing another set of flows, it is important to establish the reason for doing so. 
The answer is that in order to maximize decision making effectiveness service-wide, the 
right information must be available to the right person at the right time. The decision 
to be made may concern real-time command and control of a particular case, or it may 
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concern long-range planning at headquarters. But at the root of our information 
collection and transfer is the need to support improved decision making. 

1. Present Information Flow 

Simplified diagrams of the existing information flow are presented for the 
Search and Rescue, Law Enforcement, and Marine Safety mission areas in Figures 12 
through 14. For the first two, information flows from its source at the field unit to 
various sinks, frequently stopping at intervening levels for review and aggregation. The 
fastest reports, used for tactical command and control, are by voice, radioed to a shore 
site and then relayed by telephone up the chain of command as far as their urgency 
dictates they need go. Shortly after the incident is completed, the next set of reports go 
out; these are by message, also to the operational chain of command. They provide hard 
copy documentation of the incident, and are reviewed for proper handling of the current 
incident, analyzed for tactical planning, and archived for legal reference. Finally, the last 
set of reports go into computer databases, providing program managers with statistical 
summaries for long-range trend analysis, large-scale planning, and the like. 

The information flow for the Abstract of Operations is also depicted (Figure 
15). In many ways it constitutes a follow-on report to the other systems, but it is worth 
mentioning separately. The system epitomizes the argument for cross-functional systems, 
and represents their ultimate goal. These reports have their source at the unit, and their 
sink at headquarters. They are highly condensed cross-functional aggregates, and the 
information from which they are abstracted has almost all been typed into the several 
different systems in some form or another. Yet no mechanism for retrieving information 
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Figure 12: SAR mission area information flow, present day. 



Figure 13: ELT mission area information flow, present day. 
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Figure 14: Marine Safety mission area information flow, present day. 
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for this report from the independent systems exists, and so field units are required to 
consolidate the data manually and submit it on paper. 

Contrast the SAR and ELT information flow with that depicted for Marine 
Safety. In the latter case, information is entered just once, interactively, into a central 
database. From there, it is available nearly immediately to any authorized user, who may 
query the database to get just the information needed. Timeliness and information 
availability are greatly enhanced. The field unit is only considered an information source 
once: at the time it updates the central database. From then on, the central database 
becomes the source of almost all future information flows. (This is admittedly an 
oversimplification — Marine Safety units do complete and file paper reports that are not 
generated by MSIS, and they also send message reports of their activities to addressees 
that do not have access to MSIS. However, the general information flow is much more 
streamlined for the marine safety mission area than for the others). 

The two different information flows result in vastly different information 
processing workloads for the field units. A Marine Safety unit submits a single report 
of an incident, either while the incident is ongoing or immediately afterwards. A unit 
conducting Search and Rescue or Law Enforcement, on the other hand, submits reports 
as the incident is ongoing, then message reports, and finally database entries, all to 
different information sinks and at different times. The information in all three is largely 
similar, but is in different formats and data standards (e.g., no commonality in date 
formats: MMDDYY, DDMMYY, military date-time group, etc). 




a. SITREPS 


SITREPS are required by most operational commanders at four hour 
intervals, or "as the situation warrants." Yet even if sent at Operational Immediate 
priority, these messages generally spend most of an hour in transit to the commander, so 
some information may be five hours old. A SITREP is basically a summary of events to 
date regarding a particular case. Operating units record these events in logbooks or on 
scrap paper as they happen, then draft a report that summarizes them for the commander 
every few hours. 

b. Information System Entries 

Data is entered into the information system after the fact (except for some 
cases of MSIS). It may be entered on the same day (SIMS/ELT), or perhaps several days 
or weeks later (SARMIS). But regardless of the actual time delay, it is keyed in 
separately from the incident, with no means ior capture while the incident is ongoing. 
The information in these reports is largely the same as that in the SITREPs the unit sent 
out during the incident; although it may be in slightly different form, it too consists of 
a summary of the individual events that constituted the incident. 

2. Reengineering the Information Flow 

Information technology now allows us to dramatically improve the situation. 
By reengineering the information flows, we can significantly ease unit workloads 
dedicated to information processing, provide better and more timely information to the 
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commander, increase availability of information to other users, and provide crucial 
intelligence information to the field unit. 

a. Event-based reporting 

The basis for the new information flow is a redefinition of the basic unit 
of information. The SITREP has serious flaws as a basic unit, because of the inherent 
delay and the inability to manipulate the information. The key element of improving the 
information flow is already in place, in the event lines of SEER and SIMS/ELT. Simply 
define the individual events that heretofore comprised the SITREPs as elemental 
information units. Rather than reporting compilations of information, units can report 
things as they are happening, in the smallest meaningful granularity. 

What attributes make SEER events so suitable as the basis of reporting? To 
clearly understand, it is useful to consider information units that are too small and too 
large, respectively. For instance, an event might be described by several data fields which 
convey the fact that "Our unit is at position PP-PP.P, at time TTTT, and has sighted the 
vessel described as follows: (name, document number, etc)." All these data elements must 
be present in order for the information to be meaningful. 

Smaller information units, such as merely the name of a vessel sighted or the 
position in which it happens to be at that time, would prove to be largely meaningless, 
because they fail to provide the needed context. 

Larger information units would have greater utility, but would suffer from too 
great a time delay: while it would be nice to know that the vessel in question proved to 
have illegal drugs aboard, that fact will not become known for an hour or more after the 
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initial sighting of the vessel. Delaying the sighting report for greater completeness would 
render the earlier information valueless for real-time command and control. That is the 
situation the Coast Guard finds itelf in today, by using compilations such as SITREPs to 
summarize incidents. Even an improvement such as sortie reports, where information 
would flow from the unit in an integrated, cross-functional report that describes every 
event that occurred during a particular sortie would suffer from this drawback. 

Figures 16 and 17 graphically depict the proposed information flow, and one 
possible phased approach to achieving it. In phase 1, information would continue to flow 
from the unit to the existing stovepipe systems. OIS-1 could then query the 
heterogeneous systems, serving as a single source of information for non-real time 
information needs. This phase should include a homogeneous "front end" to the system, 
which would present a single face to the field user who is inputting data; it would collect 
each piece of information just once, and route it to the appropriate system automatically. 

In phase 2, the central database itself would become integrated, along with 
communications, and all users would conduct transactions interactively and directly. 
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Figure 16: OIS information flow, phase 1. 
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D. STAGE 4: RESOURCE ALLOCATION 

The goal of this stage is to allocate scarce resources between competing proposals 
in a rational way, based on the foregoing higher level plans and some set of comparative 
measures. The traditional measure, cost-benefit analysis, is of questionable worth for 
evaluating IS projects, because of the great uncertainties associated with both costs and 
benefits of information systems. As one alternative, Chapter IV described McFarlan's risk 
analysis model; that is presented again here, this time describing Coast Guard systems. 
Another way of thinking about these systems is developed in Chapter VI. It proposes that 
motivating cross-functionality and a common information architecture can best be done 
by drawing an analogy to public goods in classical microeconomic theory. 

It is felt that existing Coast Guard systems are low risk, technologically and 
structurally (see Figure 18). However, when systems are combined in a cross-functional 
manner, two things happen: 


• First, because of the increased size and complexity of the integrated system over 
the standalones, the technical risk increases somewhat. However, the scope of the 
proposed OIS is nowhere near the limits of current system development capabilities, 
so it is not far out along the axis. 

• Second, because of the implications which the integrated system has for change in 
the organization, the structural/behavioral risk increases dramatically. A large part 
of this risk is the reluctance of those who presently control certain information to 
share it, since information entails power within the organization. 
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Figure 18: Coast Guard systems analyzed using McFarlan's risk assessment model. 
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Even for the scope of the proposed OIS, it is felt that the organizational/structural 
risk far outweighs the technical risk (see Figure 18). Relational database theory and 
technology are at a level where associating data elements with one another in a 
meaningful, flexible way through the use of a DBMS is relatively routine, and eminently 
achievable. This is not to say that the technical risks are nil; the system is fairly 
complex, and requires careful thought and planning to build the database schema in a 
useful, flexible way. But the higher risks are certainly along the 
structural/behavioral/political axis of McFarlan's model. 
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E. STAGE 5: PROJECT PLANNING 


OIS is envisioned as a system of systems, wherein program managers continue to 
develop individual systems for their mission areas in a relatively decentralized fashion. 
In this way, they will ensure that the system meets their needs, have the ability to make 
changes, and other benefits associated with decentralization. However, systems will no 
longer be developed "in a vacuum," where the program manager builds all the pieces of 
the system and controls it in its entirety. Rather, each system will be based on the 
common infrastructure, and reap the benefits of less development time devoted to those 
items. 

Incorporating the common network and user interface in new applications should 
be almost effortless. Implementing the common database would not be quite as simple; 
new systems must be carefully fitted to the existing database, employing existing relations 
where possible, and melding new relations and relationships into the schema as well. The 
total cost of the new system, however, would be significantly lower than if it had been 
developed entirely on its own. 

F. AN ANECDOTAL DESCRIPTION 

The benefits to be realized from an integrated Operations Information System may 
become even more obvious if described anecdotally. The next two subsections depicting 
the existing and envisioned information flows in a hypothetical scenario and the ways in 
which Coast Guard decision makers at all levels will be aided by availability of better 
information. 
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1. Present Information Flow 


Coast Guard units on law enforcement patrols routinely sight and identify 
hundreds of vessels. They choose to board a few of these, ensuring compliance with 
many federal laws — e.g., those governing boating safety and documentation, fisheries, 
smuggling, and illegal immigration. The decision on whether or not to board a particular 
boat is based on several factors, including the number and description of other vessels 
nearby, course and speed the boat has been pursuing, and apparent intentions. While in 
no way definite, these factors act as very general indicators of whether or not a boat may 
be in violation of any of the afore-mentioned laws, and serve as bases for decision 
making. Other, much more informative, factors in the decision include intelligence 
reports, registration information, recent sighting reports confirming a trackline along a 
known smuggling route, and more. These are available, but take significant time and 
effort to retrieve: a voice radio call to a Coast Guard shore site, then several telephone 
calls and computer inquiries against remote databases, and a return radio call to the 
patrolling unit. This process takes the better part of an hour under the best of 
circumstances; if the shore site is busy, the information may not be available at all. And 
if more than a few queries per day come in, the shore site is overloaded. 

The result of this torturous information flow is that when a patrol unit decides 
to board, it rarely does so on the basis of information gleaned beforehand from shoreside 
databases. The boarding party goes across without knowing the registered owner or any 
intelligence about the vessel. People on board may have outstanding arrest warrants, or 
even be described as "armed and dangerous," but that information rarely gets to the patrol 
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unit before they go aboard. It would be much safer to know such things ahead of time, 
but current procedures and technology do not allow it. 

2. Proposed Information Flow: Event-based Reporting 

Now let us consider the same scenario, but with an event-based OIS in place. 
A patrolling cutter sights a vessel, triggering a real-time OIS information flow. Cutter 
personnel record the vessel's identifying characteristics (name, document number, length, 
color, etc) in their local CGSW. The shipboard system immediately sends this event 
report out over its dedicated HDN link to the OIS. Since the event was an identification, 
it also automatically addresses it to several other recipients, including the operational 
commander and "information" addressees specified by the unit commander. The OIS, 
recognizing the event report as an identification, automatically updates the database, and 
also issues a query against it. It retrieves a "tactical decision history" of that vessel — 
recent sightings, boardings, violations, and intelligence. It also produces a list of people 
associated with the boat: owner, operator, and others, along with any outstanding warrants 
or intelligence reports. This information is returned to the patrolling cutter within seconds 
after the identification information was sent out, and a copy forwarded to the operational 
commander. The cutter CO can then make an informed decision about whether to board 
the vessel in question, and the information contained in the identification event is 
available to all parties who need it in near real time. 

Information no longer flows up the chain of command, stopping along the way 
for review and aggregation. Instead, it becomes immediately available to all parties who 


82 






need it. Each information user can issue queries, or design entire applications, to 
aggregate the OIS data into the appropriate granularity for the task at hand. 

G. THE USER INTERFACE REVISITED 

The OIS user interface should rely heavily on integrated sensors and flexible input 
devices. Integrated sensors offer the ability to completely avoid human data entry, by 
automating the collection of certain frequently used data. An interface based on National 
Marine Electronics Association (NMEA) standards would link a shipboard system directly 
to the integrated navigation packages for collection of position information. Similar 
possibilities exist for weather sensors. 

Flexible input devices will be key components of the user interface. The mere act 
of writing can be a challenge aboard mobile units, especially small cutters or boats. 
Recognizing this, many units have stopped trying to write, and begun using tape recorders 
to capture radio communications and other significant events for later transfer to the ship’s 
log. Incorporating voice recognition processors would allow hands-off, natural 
interaction with the information system. Currently available off-the-shelf products allow 
discrete speech recognition with excellent accuracy for a few hundred dollars. 

There will be some difficulty in implementing this technology, because of high 
background noise in many mobile environments. In cockpits and on coxswain flats, loud 
and varying engine and wind noises are the rule. However, by using helmet-mounted 
microphones these barriers can be overcome. Variability of speech patterns from one 
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individual to another hampers current generation systems, but is easily overcome by using 
a system that is trained by the individual who will be operating it. 

In some cases, it is not possible to avoid the need to write or key in data. For these 
situations, the Coast Guard should incorporate pen-based computers, which will be 
available off-the-shelf this year. The first generation of these are especially well-suited 
to form fill-in, such as the Coast Guard would be interested in. 

H. THE OVERALL VIEW OF OIS 

A key advantage to developing a system such as this would be its reliance on the 
organization-wide information architecture to the greatest extent possible. OIS would 
consist of several applications sharing a common database, communicating via a common 
network, and presenting a single face to the user through a standard user interface. 
Systems that are presently independent would be migrated to this shared environment, and 
become modular components of the system. 

By developing the system in this fashion, it remains relatively simple to upgrade 
or replace an application module. The remainder of the system would be undisturbed. 
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VI. MOTIVATING SYSTEM DEVELOPMENT: SPECIAL CONSIDERATIONS 


A robust information architecture, and development of cross-functional systems that 
rely on such an architecture, are critically important to the organization's effective use of 
information. Yet motivating the development of these specialized projects is not easily 
done in an atmosphere where program managers develop systems independently of each 
other, and compete for budget dollars. This chapter will be devoted to further analysis 
of the special concerns surrounding motivation of cross-functional systems and the 
information architecture. It will draw distinctions between the information architecture, 
cross-functional systems, and application systems, and discuss the ramifications these 
distinctions have for development of the various classes of systems. 

The analysis here will be framed largely in terms of the degree of centralization 
versus decentralization of systems, and the proposed solutions will lean toward economic 
motivation of system developers. To this end, those topics are reviewed first. 

A. CENTRALIZATION VERSUS DECENTRALIZATION 

The debate over centralization versus decentralization in organizations is much 
wider than just information systems. Of course, the debate existed before computers did, 
and the issues at stake have changed little. The important questions regard what type of 
organizational structure, and information systems structure, are best for the smooth 
functioning of each organization. The remainder of this section recaps the typical 
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arguments in favor of centralization and decentralization, relying heavily on Wetherbe 
(1984, pp. 297-300). 

1. Arguments in Favor of Decentralization 

a. Proximity to Users 

If systems are developed by personnel close to the problem, they will tend 
to be much more likely to produce workable solutions. As systems grow more and more 
complex, it becomes increasingly important to have close interaction between users and 
developers. Only in this way will the resulting systems meet userc' needs. It is very 
difficult to specify requirements for a complex information system in advance — users 
are not familiar enough with what technology can do for them, and developers (especially 
if they are remote) are not familiar enough with the problem. By decreasing the isolation, 
one can improve the resultant system. 

b. Speed of Response 

Decentralized computer hardware and support personnel can respond more 
quickly to user needs than centralized resources. 

c. Profit and Loss Responsibility 

The costs of decentralized resources can be easily charged to the 
responsible departments, making them more sensitive to the tradeoffs of cost versus value 
derived from the system. The departments will be much more prone to weigh requests 
carefully if they are responsible financially. 
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2. Arguments in Favor of Centralization 

a. Economies of Scale 

For very expensive items, it is most cost-effective to use only a few, and 
centralize them so that the entire organization has access to them. This applies especially 
to large computer hardware items, and most of all to organization-wide databases. It 
would be technically possible to keep separate copies of the complete OIS database at 
several locations, but the cost of doing so would be extreme. Beyond the mere 
duplication of hardware is the huge problem of maintaining consistency of the distributed 
databases. It is much more feasible to access a central database, despite 
telecommunications costs, than to try to maintain a consistent distributed database. 
Research may change this, but for the foreseeable future, centralized data will be by far 
the most practical. 

b. Limited Personnel Resources 

Specialists in any field, including computers and systems, are scarce and 
expensive resources. By centralizing them, it is possible to achieve a sort of "personnel 
economy of scale." At the central location, they are more likely to be kept fully occupied 
than if distributed, so it makes economic sense to keep them there. 

c. Organization-wide Consolidation of Information 

"Financial and operating data are readily consolidated for reporting and 
evaluation purposes. Without centralization, consolidation is usually obstructed by 
incompatibilities of different system design, coding schemes, and data formats." 




(Wetherbe, 1984, p. 298). This quote strikes at the heart of the argument for cross- 
functionality. The Coast Guard should design cross-functional systems, systems that rely 
on a common architecture. In this way, it is possible to reap the advantages of 
decentralized development and control and those of centralized information consolidation 
at the same time. 

d. Ease of Control 

Centralized resources are easier to control. However, this ease of control 
is counterbalanced by a tendency to stifle initiative. Wetherbe states the classic argument 
that "through centralized systems development, uniformity can be achieved." (Wetherbe, 
1984, p. 298). But with the advent of client-server or distributed systems, the entire 
system need not be centralized. By centralizing the bare minimum, the critical 
information architecture, and adhering to the rapidly developing open standards, it is 
possible to have uniformity while still achieving the advantages of decentralized system 
development. 

B. PUBLIC GOODS AND SERVICES 

The next step in developing the special distinctions between the information 
architecture, cross-functional systems, and application systems is to describe what it is 
that typifies a "public good." The discussion begins with a definition of the limited roles 
government should take in a marketplace, according to classical microeconomic theory. 
Later, the environment for systems development in the Coast Guard will be compared to 
a marketplace for goods and services. In this analogy, program managers are viewed as 
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utility-maximizing individual consumers, and the office of Command, Control, and 
Communications is viewed as a supervisory authority like the "government" of that 
theory. 

In most instances, of course, a free market society experts government to let the 
marketplace function on its own. However, there are four cases in which government 
should become involved: 

• To provide a special category of goods and services, normally referred to as public 

goods. 

• To correct imperfections (through regulation). 

• To redistribute income (through taxes and subsidies). 

• To protect rights of parties. (Gates, 9/18/90) 

A classic example of public goods, with room for discussion of the government's 
other roles, is the public network of roads and bridges. It provides society with a vital 
ability to transport goods and services. However, this network was not developed by the 
people and companies who use it. Rather, it was developed by the government (which 
is regarded here as a monolithic whole, with the different levels of government ignored). 
The majority of the system was directly funded by the government, and is completely 
open to public use. 

In some cases, individuals or firms choose to build their own roads, especially short, 
special-purpose links to the public roadway network. This is certainly permitted, even 
encouraged. However, these private roads must be built according to government 
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standards, and must not be built so as to be illegal. These standards illustrate the 
regulatory powers of government. 

Finally, government may decide that society would benefit from private 
development of certain roads or connecting thoroughfares, but not feel that they are 
completely in the interests of the general public. It may then decide to encourage private 
entities to develop those roads by offering a subsidy. This may be viewed as a cost¬ 
sharing arrangement that provides benefits for the private entity and also for society. In 
economic terms, the government subsidy allows the private entity to "internalize the 
external benefits" — since the private entity is doing something that benefits society, 
society assumes a portion of the costs. Conversely, if a private entity is doing something 
that costs society, such as polluting the air or creating a noisy environment, government 
may impose a tax on the entity. The amount of this tax approximates the cost to society 
of the entity’s activity. (Rasmussen and Haworth, 1979, p. 458). 

In summary, the government (or some regulatory authority) has several important 
roles in the marketplace, which will be compared to the roles for a regulatory division 
within the Coast Guard. These roles are: 

• To provide goods and services that benefit society as a whole 

• To regulate private economic activity, preventing illegal or immoral acts. 

• To help private entities realize rewards for indirect benefits that they create for 
society, in the form of a subsidy. Conversely, to ensure that indirect costs they 
impose on society are made real for the private entities, in the form of a tax. 


90 







C. DEVELOPING APPLICATION SYSTEMS 


Application systems fill special end-user needs, and are frequently best developed 
in a decentralized fashion. System developers are much closer to the users, so the close 
coordination that is vital to a successful development effort is much easier. Also, the 
costs and benefits of an information system proposal are likely to be weighed much more 
carefully if they are chargeable to the department making the proposal. 

The program managers at Coast Guard headquarters are the ideal sponsors of the 
existing, independent application systems (MSIS, SARMIS, LEIS, etc). They have a 
more direct interest in the success or failure of their MIS than any other office. They are 
likely to consider the costs carefully in relation to other program expenditures. And 
although they are not decentralized geographically, they are significantly more 
decentralized organizationally than the Information Systems Division, G-TTC. 

Considered in terms of the economic marketplace analogy, program managers act 
largely to maximize their utility for their own programs, with little consideration for the 
benefits or costs their efforts may have to other programs, nor for the benefits they may 
be able to receive from other programs. For stovepipe application systems, this situation 
is acceptable, in fact desirable — applications are optimized for the good of the programs 
they serve. However, when systems must become cross-functional, this situation needs 
massaging in order to provide the best solution. 
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D. DEVELOPING CROSS-FUNCTIONAL SYSTEMS 


The program managers also have a vital interest in any cross-functional system that 
affects their programs. Each would certainly like to have complete control over such a 
system, to ensure it meets program needs perfectly. However, by their very nature, 
cross-functional systems benefit the entire organization, not just a single department. It 
is difficult or impossible to optimize systems for the good of both the whole organization 
and of individual departments. Therefore, it behooves the organization to devise a 
mechanism for ensuring cross-functional systems are optimized for the good of the 
whole, and if necessary be sub-optimized for the individual divisions. 

This concept is already recognized by the Coast Guard. Coast Guard IRM 
Principles clearly state that "individual IRM solutions may be suboptimized for the greater 
good of the Coast Guard." (COMDTINST 5230.41, 31 May 90, p. 2). Program managers 
are indeed cooperating on next generation systems development at a level not seen before. 
However, there is no firmly established mechanism for encouraging them to adhere to this 
principle, and no means of discouraging them from continuing independent system 
development should they choose to do so. 

The roles of government in the marketplace suggest a solution to this dilemma. Just 
as government can use subsidies, taxes, and regulation to encourage, discourage or 
prohibit certain behaviors on the part of utility-maximizing individuals or firms, G-TTC 
should be empowered to use these mechanisms to foster development of cross-functional 
systems. The IRM Principles already state the desired result, that systems be built for the 
good of the whole. But without a mechanism for implementation, a principle may do 
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little for the actual state of affairs. The principle should be embodied in a 'regulatory 
system," requiring optimization for the good of the whole. This kind of control rests with 
the budgetary process, where G-T has had no authority until recently, and even now only 
review, not approval. The role of G-T in the budgetary process should be enhanced to 
provide the necesary mechanism for encouraging cross-functional systems and 
discouraging stovepipes. 

The regulatory system would encourage cross-functional systems by a "carrot and 
stick" approach, providing subsidies to program managers who develop them and taxing 
those who do not. The subsidy could involve a direct transfer of funds to the program 
from a special account established for such a purpose and managed by G-TTC. It could 
define a certain level of technical or management support from G-TTC. Finally, it could 
entail some form of lower communication charges for using the Hybrid Data Network, 
or other parts of the information architecture (below). The "taxes" would be largely the 
opposite of the possibilities for subsidies. 

E. DEVELOPING THE INFORMATION ARCHITECTURE 

The information architecture is quite different from application systems. Rather 
than benefitting one group of end users, the information architecture is a special 
infrastructure which benefits the entire organization. It is of a magnitude that can benefit 
from economies of scale by centralizing. And it requires centralized planning and control 
in order to provide services to all users. A robust information architecture is so likely 
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to be prohibitively expensive for any single system, yet would prove very beneficial to 
system developers once implemented. 

The information architecture is clearly a special case, which should be provided on 
an organization-wide basis. It should be funded and managed as a public good, an 
element of society's infrastructure. The Office of Command, Control, and 
Communications (G-T) should establish standards for the architecture, obtain funding for 
it, and maintain control over it, providing access to it for all system developers. This 
approach has several benefits. One of the largest comes from the network externality of 
economic theory. If a telephone network has access to only a hundred subscribers, it is 
worth very little to a potential subscriber to join the network because of the limited 
number of others that can be reached. Yet if the network has a hundred million 
subscribers, or at least reaches all persons with whom the potential subscriber wants to 
communicate, it is worth a great deal more. The Hybrid Data Network, as a cornerstone 
of the Coast Guard's information architecture, should be controlled by a central authority 
within the agency for the good of the whole organization. 

Another benefit from the information architecture is in reduced costs for developers 
of cross-functional systems, or even stovepipe applications. By relying on existing 
standards in the area of telecommunications, database, and user interface, developers 
would be able to dramatically reduce the time and cost required for new systems. It is 
not at all unreasonable to expect that such development efforts would be less than half 
as costly as completely independent systems. 
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Finally, the Coast Guard should formalize an initiative that is growing within G- 
MIM. That office is developing the contract specifications for the new Marine Safety 
Network. They hope it can be used as a common contract vehicle for MIS projects by 
all program managers. This could significantly reduce some of the up-front contracting 
work, allowing system developers to concentrate more on the system requirements, rather 
than the mechanics of how to acquire it. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


Information technology, well implemented, can clearly provide major benefits to the 
Coast Guard. Existing systems do not provide the organization with a smooth information 
flow. Cross-functional systems, based on a robust information architecure, will 
dramatically improve information flow, reduce redundant use of personnel time for data 
entry, reduce duplication of effort across programs, and improve availability of 
information to decision makers. 

A. CONCLUSIONS 

Information does not flow smoothly, but follows a torturous path through the 
organization. It is frequently not available to employees who could use it to make better 
decisions for the organization as a whole. 

Existing systems suffer from a large degree of overlap and inconsistency in 
information content, but offer no means for eliminating the overlap or reconciling the 
inconsistencies. This forces repetitive data entry into separate systems, and increases 
workload and frustration for field personnel. 

Existing systems suffer from poor connectivity and user interfaces, which combine 
to make it difficult to retrieve information. As a result, decision makers do not get 
information they should have. Others are forced to spend significant time and effort, both 
in learning how to retrieve information, and in actually performing the process. 
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Cross-functional systems offer a means of correcting many of these problems. By 
improving the flow and availability of information within the organization, they offer 
opportunities to improve effectiveness of the existing organizational structure by re¬ 
designing processes. Further, they offer the opportunity to re-engineer the organization 
to better serve the public. 

B. RECOMMENDATIONS 
1. Future Development 

The Coast Guard should aggressively pursue its stated policy of developing 
cross-functional systems. Specifically, it should develop a cross-functional Operations 
Information System (OIS), as described in Chapter V. 

OIS, and other cross-functional systems, should rely on a robust information 
architecture. This should consist of a common telecommunications network, a common 
user interface, and a small number of common databases. Development and maintenance 
of the information architecture should be centralized, as described in Chapter VI. 

Application systems should be cross-functional whenever possible, and this 
should be encouraged as part of the budget process with some form of subsidy, as 
described in Chapter VI. Similarly, stovepipe systems should be discouraged, through 
some form of tax. Application systems should be developed and maintained in a 
decentralized fashion as much as possible. New applications should be implemented in 
a scheme of phased deliverables, tying into existing cross-functional systems a piece at 




2. Existing System Upgrades 

Existing applications should be upgraded, because of the long lead time until 
they can be incorporated into a cross-functional system. However, the upgrades should 
not disregard the potential for cross-functionality. Rather, upgrades can pave the way for 
smooth transitions to eventual cross-functional systems. Specific recommendations follow. 

a. Data Storage and Retrieval 

Transition the data from file processing systems to database management 
systems. Use one of the Coast Guard’s standard DBMS packages, either Progress™ or 
Oracle™. Rely on the Data Element Naming Conventions when designing the schema 
for the upgraded database. In this way, transferring the data to a cross-functional 
database later will be significantly easier. 

b. Telecommunications Solutions 

Transition from independent telecommunications solutions to the Hybrid 
Data Network. Build support for the HDN into applications, and hide the task of 
establishing connections to the central site from the user. 

c. User Interface Design 

Define a style guide for applications. This should rely on menu-driven 
interfaces, using the soft-key approach to defining the function keys. Menu structures 
should be similar, and thus familiar, between applications. Future applications should be 
written to the XVT API, providing the additional ease of use of a Graphical User 
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Interface when the end user's workstation supports it. The combination of style guides 
and GUIs will greatly enhance user's productivity. 

Transition from the SARMIS approach, which presents users one question 
at a time on screen, to something like the SIMS/ELT approach. This presents the user 
with a form containing logically related data elements, allowing faster data entry and 
better understanding of how much of the task has been completed. 

Build support for integrated sensors and flexible input devices into future 
applications. The key is to integrate information systems into the operating units' work 
patterns as closely as possible, so that their attention may be focused on conducting 
operations rather than on gathering or reporting information in support of operations. 

d. Distributed Processing 

Employ the processing power of the Standard Workstation to provide the 
user interface, establish connections, and maintain local databases. Avoid applications 
that treat the CGSW as a dumb terminal. 
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APPENDIX A: U. S. COAST GUARD ORGANIZATION 


The following pages describe organizational relationships within and affecting the 
Coast Guard. Figure 19 shows the Department of Transportation organization. Figure 
20 shows the operational chain of command in the Coast Guard. Figure 21 shows the 
staff organization at Coast Guard Headquarters. 
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Figure 19: Department of Transportation organization. 
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Figure 20: U. S. Coast Guard organization. 
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APPENDIX B: CROSS-FUNCTIONAL DATABASE PROTOTYPE 


This Appendix contains a summary of a database project done by the author and 
another student (Glidden and Marsh, Dec 90). It was designed as a prototype cross¬ 
functional system to support two of the Coast Guard's missions, Search and Rescue (SAR) 
and Enforcement of Laws and Treaties (ELT). 

Tables 13 and 14 in Chapter VI describe the 78% overlap between the information 
in the Report of Boarding, form CG-4100, and the SAR Unit Case Folder, form CG- 
16130. At first thought, it is hard to believe that nearly 80% of the data in the two 
systems is the same. However, when one thinks about the type of information the Coast 
Guard collects in terms of data objects, the reason for the overlap becomes clear. This 
list describes the objects: 

INCIDENT This is the main object in this prototype. The bottom line is that the 
Coast Guard collects all this information from field units and stores it in 
a central computer because something happened. It happened 
somewhere, and at a certain time and date. When translated into 
relations and relationships, the data occupies roughly 24 data items in 
three tables. 

WEATHER Every incident has a weather report associated with it. Roughly 20 data 
items in a single table. 

PERSON Nearly every incident involves people, either as crewmembers of a 
boarded vessel, or aboard SAR case subjects, or both. Roughly 25 fields 
in two tables. 

VESSEL Nearly every incident also involves a boat. Roughly 34 data items in a 
single table. 
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SAR CASE Information that is unique to SAR cases: unit case number, nature of 
distress, lives lost and saved. Roughly 10 data items in two tables. 

BOARDING Information that is unique to law enforcement boardings: boarding report 
number, name and rank of boarding officer, violation codes, and remarks. 
Roughly 19 data items in four tables. 


The following pages are key excerpts from the design documents for this simple 
integrated system, describing the data objects, the relational diagram (Figure 22), and the 
data dictionary. 
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Requirements 


I. Data Requirements 

We defined six major objects in the environment of a Coast Guard field unit 
tracking operational data, which are: 

• The VESSELS which are the subject of operations. 

• The PERSONnel which are the subject of operations. 

• The INCIDENTS which operations involve. 

• The WEATHER at the time of an incident. 

• The SAR CASEs which the unit conducts. 

• The BOARDINGS which the unit conducts. 

In defining the objects involved in this application, we began by considering, from 
our personal experience in the field, what general categories of information were involved 
in the SAR and LE missions. It was clear that both normally involve vessels, although 
some few missions do not; likewise, nearly all missions involve people. Also common 
to both mission areas are weather information and general descriptive data, such as 
position, date, and time. These four objects are part of nearly every mission; the 
mission-specific objects include details of the damage and nature of distress, for SAR 
cases, and of the boarding and any citations, for LE cases. 

We validated these object definitions by examination of the paper forms presently 
in use: a SAR case folder, form CG-16130, and a Report of Boarding, form CG-4100. 
These forms are included as Appendix F. 
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Figure 22. Relational Diagram. 
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A30 

Middle initial 

A1 

Nationality 

A2 

Last name 

A25 

Hull Ident Number 

A17 

Street Address 

A45 

Sail Number 

A10 

City 

A2 

Radio Call Sign 

A8 

State 

N 

RT License Number 

A10 

Zip 

N 

Fish license Number 

A15 

Phone 

N 

Make 

A40 

Birthdate 

D 

Model 

A30 

Height 

N 

Model year 

N 

Weight 

N 

Hull Material 

A1 

Hair Color 

A3 

Hull Color 

A3 

Eye Color 

A3 

Superstructure Color 

A3 

Title 

A4 

Length 

N 

Personnel Status 

A1 

Draft 

N 

Courses 

A1 

Net Tons 

N 

Missing after search? 

A1 

Propulsion 

A1 



Horsepower 

N 



Use 

A1 



Engine Compartment 

A1 



Fuel Compartment 

A1 



Construction 

A1 



Type of Boat 

A1 



Adult PFD's 

N 



Child PFD's 

N 



Equipment 

A12 



POB 

N 



Missing after search? 

A1 



Estimated $ value 

$ 



Damage $ in SAR 

$ 
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REPORTING-SOURCE 


ASSISTING UNITS 


Incident#** 

A7 

Incident#** 

A7 

Name 

A40 

QPFAC# 

N 

Phone 

N 

Unit-name 

A30 

Street Address 

A45 

Their-Unit-case# 

A7 

City 

A25 

Their-boarding-report# 

A7 

State 

A2 



Relationship 

A50 




INCIDENT-PERSON 

Incident#** 

A7 

INCIDENT-VESSEL 
Incident#* * 

A7 

DL#** 

A15 

Document#** 

A6 

SSAN** 

N 

Registration#* * 

A8 

Crew-posit 

A1 




INJURIES 


VIOL-CODE 


Incident#* * 

A7 

Incident#** 

A7 

SSAN** 

N 

Boarding-report#* * 

A7 

Driver's-license#* * 

A15 

Viol-code 

A2 

Medical-code# 

A10 

Remarks 1 

A60 

Remarks 1 

A60 

Remarks2 

A60 

Remarks2 

A60 




UNSAFE-COND-CODE 

Incident#* * 

A7 

BOARDING REMARKS 
Incident#** 

A7 

Boarding-report#* * 

A7 

Boarding-report#* * 

A60 

Unsafe-cond-code 

A2 

Remarks-line# 

A2 

Remarks 1 

A6 

Remarksl 

A60 

Remarks2 

A60 




SUB-UNITS 


Unit-case# 

A7 

Sub-unit-ID 

A8 

Sub-unit-type 

A2 
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